为什么Xcode在创建经过地址清理的版本时会定义_LIBCPP_HAS_NO_ASAN？ [英] Why does Xcode define _LIBCPP_HAS_NO_ASAN when creating an address-sanitized build?

问题描述

Xcode 7允许使用地址清理器查找C / C ++中的内存问题。

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

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

打开地址消毒器传递编译和链接器标志 -fsanitize = address 并定义 _LIBCPP_HAS_NO_ASAN 。

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

从命令行构建我的库并在未定义 _LIBCPP_HAS_NO_ASAN 的情况下在经过清理的版本上运行测试时，我看到了不可重复的地址清理器报告的内存访问问题。像Xcode一样，定义 _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.

为什么要使用AppleClang7定义 _LIBCPP_HAS_NO_ASAN 以避免在libcxx中出现内存访问问题？

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

推荐答案

从与Sean McBride（不在StackOverflow上进行的讨论）的讨论中，已知在混合已检测代码和非检测代码时存在虚假的内存越界错误的已知问题：

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:

从Anna Zaks的 http： //lists.apple.com/archives/xcode-users/2016/Jan/msg00077.html ：

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

但是，在C ++容器溢出检查中有一个极端的情况，这种情况可能并不总是成立。特别是，如果libc ++容器与已检测的交叉（已重建） （使用ASan）到非仪表代码，Address Sanitizer可能会报告容器溢出误报。 （想象两个库，它们都使用相同的std :: vector，只有其中一个被检测。来自非仪器模块的Push_back不会将新添加的元素的内存标记为有效。从检测的代码访问该元素将触发误报。）

"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.)"

我希望这个问题对其他人有帮助，因为这个问题已经占用了我大量的时间。Asan很好，但是这个信息很难找到。

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.

这篇关于为什么Xcode在创建经过地址清理的版本时会定义_LIBCPP_HAS_NO_ASAN？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！