The patch is tracked by http://reviews.llvm.org/D10859
Stefan, Thank you for the test case! Anna. On Sunday, June 21, 2015 at 10:00:11 AM UTC-7, kcc wrote: > > > > On Sun, Jun 21, 2015 at 7:04 PM, Stefan Haller <[email protected] > <javascript:>> wrote: > >> I'd be willing to work on a patch (it looks like the fix itself is >> straight-forward), but I'd need some guidance as to how to write the >> tests and where to put them, > > > You may take a look at > https://github.com/llvm-mirror/libcxx/blob/master/test/std/containers/sequences/vector/asan.pass.cpp > > >> so I'm not sure this would be efficient. >> >> In case anyone else wants to give it a go, here's another test case that >> doesn't depend on boost, so this might serve as a basis for a test: >> >> #include <vector> >> #include <cassert> >> >> /* Stupid toy iterator; it implements just enough so that the code >> below compiles, and so that the vector::insert specialization >> for non-forward_iterators is taken. */ >> class MyInputIter : public std::iterator<std::input_iterator_tag, int> >> { >> public: >> MyInputIter(int* ptr) : ptr_(ptr) {} >> friend bool operator!=(const MyInputIter& i1, const MyInputIter& i2) >> { return i1.ptr_ != i2.ptr_; } >> MyInputIter& operator++() { ++ptr_; return *this; } >> int operator*() const { return *ptr_; } >> private: >> int* ptr_; >> }; >> >> int main(int argc, const char * argv[]) >> { >> std::vector<int> v; >> v.reserve(1); >> int i = 42; >> v.insert(v.begin(), MyInputIter(&i), MyInputIter(&i + 1)); >> assert(v[0] == 42); >> return 0; >> } >> >> -Stefan >> >> >> Konstantin Serebryany <[email protected] <javascript:>> wrote: >> >> > On Sat, Jun 20, 2015 at 8:45 AM, Anna Zaks <[email protected] >> <javascript:>> 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. >> >> -- >> 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] <javascript:>. >> 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.
