Container-overflow false positive with uninstrumented code

[ramosian-glider]

Originally reported on Google Code with ID 362

Imagine two modules, both using std::vector, only one of them is instrumented. Push_back
from the non-instrumented module will not unpoison the memory for the newly added element.
Access from the instrumented module will trigger a false report.

Note that these two modules don't need to share a common instance of std::vector. Theoretically,
it is possible for the linker to choose the uninstrumented version of std::vector::push_back
(if it was not inlined) to be called from the instrumented module.

Reported by eugenis@google.com on 2014-12-08 09:26:48

[Myushu]

Hi,

Is there a way to work around this issue? (that's not "recompile all your deps with -fanitize)

Thanks.

[yugr]

Is there a way to work around this issue? (that's not "recompile all your deps with -fanitize)

Probably not (and yes, this seems to be a serious limitation of container sanitization).

[kcc]

Not that I know of.
https://github.com/google/sanitizers/wiki/AddressSanitizerContainerOverflow#false-positives

[yugr]

@kcc shouldn't container annotations be disabled by default then? Because they otherwise prohibit separate sanitization which is a very popular use-case...

[kcc]

Default values are hard :)
Our major customers would not care about default values because they set those values themselves,
e.g. see here, so we mostly need to worry about smaller customers.

If we make this feature off by default users will never know about it (people generally don't read docs).
We've found enough container overflows to think that this would be very sad.
On the other hand, if we keep the feature on by default, some of the users will be confused by the false positives. Currently asan prints a link to the above wiki explaining the situation, so the confusion is hopefully minimal. And it will be an extra push for Linux distros to finally start shipping asan-itized libraries.

[dvyukov]

Is there a way to work around this issue? (that's not "recompile all your deps with -fanitize)

You can work around the issue by running with ASAN_OPTIONS=detect_container_overflow=0 env var.

But note that AddressSanitizer finds only a subset of bugs. And to use ThreadSanitizer and MemorySanitizer most likely you need to rebuild all you deps.

[vendethiel]

Thanks for your answers!

[yugr]

So close as not-a-bug then?

[morehouse]

WAI.

[yugr]

FYI GCC disables container instrumentation by default (user needs to define _GLIBCXX_SANITIZE_VECTOR explicitly), probly because they care more about "small" users.