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, 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.
