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]
> <javascript:>> 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_;
}
...
>
>> 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] <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.
