Why does Xcode define _LIBCPP_HAS_NO_ASAN when creating an address-sanitized build?

Question

Xcode 7 allows address sanitizer to be used to find memory issues in C/C++.

https://github.com/google/sanitizers/wiki/AddressSanitizer

Turning on address sanitizer passes the compile and linker flag -fsanitize=address and also defines _LIBCPP_HAS_NO_ASAN.

When building my library from the command line and running tests on a sanitized build without defining _LIBCPP_HAS_NO_ASAN I see non-repeatable address-sanitizer-reported memory access issues. Defining _LIBCPP_HAS_NO_ASAN, as Xcode does, gets rid of the sanitizer issues but I'm curious as to why it needs doing.

Why do I need to define _LIBCPP_HAS_NO_ASAN with AppleClang7 to avoid getting memory access issues in libcxx?

Answer 1

From discussion with Sean McBride (who is not on StackOverflow) there are known issues with spurious memory-out-of-bounds errors when mixing instrumented and non-instrumented code:

From Anna Zaks on http://lists.apple.com/archives/xcode-users/2016/Jan/msg00077.html:

"Generally, one does not need to rebuild any code that is being linked into sanitized code."

"However, there is one corner case in C++ container overflow checking, where this might not always hold. Specifically, if libc++ containers cross from instrumented (rebuilt with ASan) to non-instrumented code, Address Sanitizer might report container overflow false positives. (Imagine two libraries, both using the same std::vector, only one of them is instrumented. Push_back from the non-instrumented module will not mark the memory for the newly added element as valid. Accessing the element from the instrumented code, would trigger a false positive report.)"

I hope this question helps someone else as this problem has consumed a considerable amount of my time. Asan is great but this info was hard to find.