On Sat, Jun 20, 2015 at 8:45 AM, Anna Zaks <[email protected]> wrote:
> > > On Friday, June 19, 2015 at 8:03:04 PM UTC-7, kcc wrote: >> >> We've seen a similar case when a library (I think it was boost) was not >> instrumented with asan >> and as the result some parts of std::vector implementation did not have >> the instrumentation >> (there was a a kind of ODR violation: instrumented bits of std::vector >> were mixed with non-instrumented bits). The solution was to instrument >> boost too. >> This situation is specific to container-overflow bugs, so you may just >> disable this functionality for now >> (ASAN_OPTIONS=detect_container_overflow=0) >> >> On Sat, Jun 20, 2015 at 5:18 AM, Anna Zaks <[email protected]> wrote: >> >>> I can reproduce this. >>> >>> The error happens in the call to __alloc_traits::construct inside of >>> vector<_Tp, _Allocator>::insert(const_iterator __position, >>> _InputIterator __first, _InputIterator __last) >>> >>> That insert method does not seem to call __RAII_IncreaseAnnotator. >>> >>> >> Do you mean that the code is not there, or that it is not getting called? >> >> > > Code is not there: > > > template <class _Tp, class _Allocator> > > template <class _InputIterator> > > typename enable_if > > < > > __is_input_iterator <_InputIterator>::value && > > !__is_forward_iterator<_InputIterator>::value && > > is_constructible< > > _Tp, > > typename iterator_traits<_InputIterator>::reference>::value, > > typename vector<_Tp, _Allocator>::iterator > > >::type > > vector<_Tp, _Allocator>::insert(const_iterator __position, _InputIterator > __first, _InputIterator __last) > > { > > #if _LIBCPP_DEBUG_LEVEL >= 2 > > _LIBCPP_ASSERT(__get_const_db()->__find_c_from_i(&__position) == this, > > "vector::insert(iterator, range) called with an iterator not" > > " referring to this vector"); > > #endif > > difference_type __off = __position - begin(); > > pointer __p = this->__begin_ + __off; > > allocator_type& __a = this->__alloc(); > > pointer __old_last = this->__end_; > > for (; this->__end_ != this->__end_cap() && __first != __last; > ++__first) > > { > > __alloc_traits::construct(__a, _VSTD::__to_raw_pointer(this > ->__end_), > > *__first); // <--- OVERFLOW IS REPORTED > HERE. > ++this->__end_; > It's quite surprising that we haven't seen this before... The fix should be somewhere here, similar to other methods of std::vector. I won't be able to work on it until mid July (vacation, no access to a proper PC), but anyone is welcome to send a fix (with a test). } > ... > > >> >>> Anna. >>> >>> On Friday, June 19, 2015 at 5:17:56 PM UTC-7, Alexey Samsonov wrote: >>>> >>>> +Kuba, Anna >>>> >>>> in case they have any ideas, or are able to reproduce it under Apple >>>> Clang. >>>> >>>> On Thu, Jun 18, 2015 at 9:37 AM, Stefan Haller <[email protected]> >>>> wrote: >>>> >>>>> I'm getting a container overflow failure that I think is a false >>>>> positive; but I don't understand what's going on, so I'm posting here >>>>> instead of filing an issue. Here's the most stripped-down example that >>>>> I >>>>> could come up with: >>>>> >>>>> #include <vector> >>>>> #include <boost/range/any_range.hpp> >>>>> >>>>> template <typename T> >>>>> using AnyRange = >>>>> boost::any_range<T, >>>>> boost::random_access_traversal_tag, >>>>> T, >>>>> std::ptrdiff_t>; >>>>> >>>>> int main(int argc, const char * argv[]) >>>>> { >>>>> std::vector<int> v{1, 2, 3}; >>>>> v.erase(v.begin() + 1); >>>>> int i = 42; >>>>> AnyRange<int> range{&i, &i + 1}; >>>>> v.insert(v.begin() + 1, boost::begin(range), boost::end(range)); >>>>> assert(v[0] == 1); >>>>> assert(v[1] == 42); >>>>> assert(v[2] == 3); >>>>> return 0; >>>>> } >>>>> >>>>> This triggers the container overflow error inside the insert call, when >>>>> it tries to copy-construct the int at v.end(), which is inside the >>>>> allocated memory of the vector. >>>>> >>>>> Replacing the insert line with >>>>> >>>>> v.insert(v.begin() + 1, &i, &i + 1); >>>>> >>>>> makes it work. Also, changing the Reference argument of the any_range >>>>> (third template argument) to "T&" or "const T&" also makes it work. And >>>>> of course, running the test without AddressSanitizer succeeds, so it >>>>> doesn't look like it's actually overwriting memory. >>>>> >>>>> I tested this with boost 1.55 and 1.56. I'm on Mac OS X 10.10, with >>>>> clang++ version "Apple LLVM version 7.0.0 (clang-700.0.53)", x86_64. >>>>> AddressSanitizer is the one that comes bundled with the Xcode 7 beta >>>>> (not sure how to find out which version or revision that is). >>>>> >>>>> Any idea what's going on? >>>>> >>>>> Thanks, Stefan. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "address-sanitizer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Alexey Samsonov, Mountain View, CA >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "address-sanitizer" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
