On Sun, Jun 21, 2015 at 7:04 PM, Stefan Haller <[email protected]> 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]> wrote: > > > 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. > > -- > 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.
