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