问题标签 [address-sanitizer]

以下代码用于将 a 转换sockaddr为 asockaddr_in6以获取 IPv6 地址：

当我使用 Address Sanitizer 在 Xcode 9 beta 中运行代码时，执行会在这一行停止：

使用以下消息（加上大量内存信息）：

AddressSanitizer：堆栈缓冲区溢出地址 0x000131810077 在 pc 0x00010a3c06d5 bp 0x7fff55ded010 sp 0x7fff55ded008 在 0x000131810077 线程 T0 处读取大小 16

我可以理解，ASAN 担心我正在阅读超出边界sockaddr以获取完整信息sockaddr_in6（sockaddr即 16 字节，sockaddr_in6即 28 字节）。

但由于这个原因，我似乎无法使用 ASAN 测试我的应用程序的其余部分。任何使用withMemoryRebound都会使 ASAN 跳闸似乎有点奇怪。

我尝试以不同的方式编写它，甚至Data用作字节的容器。但我似乎总能找到触发 ASAN 的解决方案。

我的代码有问题吗？
或者我可以以某种方式忽略 ASAN 中的这个功能吗？

我在我的所有项目中都使用 AddressSanitizer 以检测内存泄漏、堆损坏等。但是，当在运行时通过 dlopen 加载动态库时，AddressSanitizer 的输出还有很多不足之处。我写了一个简单的测试程序来说明这个问题。代码本身并不有趣，只是两个库，一个在编译时通过 -l 链接，另一个在运行时使用 dlopen 加载。为了完整起见，这里是我用于测试的代码：

我使用以下命令编译了上面的代码：

当我运行程序时，我得到以下输出（我必须事先导出 LD_LIBRARY_PATH 才能找到 libasan）：

虽然检测到泄漏，但 AddressSanitizer 似乎无法解析通过 dlopen 加载的库的模块名称、函数名称和行号（打印 ( <unknown module > ) 代替），而在编译时链接的库可以正常工作。我的问题是：

是否可以使用一些编译器开关来解决这个问题，或者当涉及使用 dlopen 加载的库时，是否无法使用 AddressSanitizer 获取更多信息？显然可以找到 llvm-symbolizer ，否则不会有其他库的行号。运行程序

不会产生不同的输出。我用 g++ 编译了程序，但输出保持不变。我还通过 asan_symbolize.py 管道输出，但没有任何改变。我不知道接下来该往哪里看。我的想法有根本性的错误吗？在动态加载库方面，我不是专家。

你们知道为什么 AddressSanitizer 会使用一组完全不同的库吗？

例如，当我将输出与 string.h 中的标准 strcmp 进行比较时，我试图重新创建 strcmp，但我意识到使用 gcc 正常编译它会输出差异，但添加了 -fsanitize=address 标志给我 1, 0, -1 输出。

gcc 和 clang 的行为方式相同

顺便说一句，我在 OSX 10.11.6 上。这种行为是 MACOS 独有的还是其他系统有类似的效果？

顺便说一句，从我读到的内容来看，GNU C 库的 strcmp 输出差异，而 Apple 版本的输出只有 1、-1 和 0。所以这对我来说更令人费解，因为 MACOS 中的 gcc/clang 似乎默认情况下使用 gnu libc，并在使用 -fsanitize=address 标志时以某种方式转移到苹果的 libc 版本。

如果有人可以向我解释这一点，我将不胜感激。顺便说一句，以防万一，这是我的 gcc 配置：

我正在将内核地址清理程序（KASan）从 linux 移植到另一个操作系统（我们称之为操作系统）。该操作系统使用工具链编译，arm-none-eabi我将以下与 asan 相关的标志传递给编译器：

-fsanitize=kernel-address --param asan-globals=1 --param asan-stack=1 --param asan-instrumentation-with-call-threshold=0

我还实现了不同的__asan_*功能，包括__asan_register_globals和__asan_unregister_globals。

我的问题是编译器只插入__asan_load*,__asan_store*和__asan_handle_no_return函数并忽略全局变量和堆栈。

我进行了调查，发现在 Linux 编译器中插入了全局和堆栈的检测，但 Linux 使用arm-linux-gnueabi工具链。

任何人都可以解释为什么--param asan-globals=1并且--param asan-stack=1不影响使用arm-none-eabi工具链生成的代码吗？或者只是为进一步搜索设定方向。

谢谢。

目前我遇到了一个已知的 asan 问题（见报告）

是否可以使用环境变量来停止使用 asan 来防止此错误？

或者至少阻止这个错误是致命的。

我想这样做的原因是生成代码时发生了失败的命令，但我想将 asan 用于生成的二进制文件。为生成的二进制文件和最终的二进制文件设置不同的 CFLAGS 是可能的，但如果不对其他人进行硬编码，就很难做到。所以我想要一种在构建步骤中禁用 asan 的方法，但之后再使用。

编辑：如果它有用，这发生在一个非常简单的程序中：错误，代码。

我正在尝试在服务器上对我怀疑与缓冲区溢出有关的问题进行一些调试，因此我尝试编译我的代码-fsanitize=address以启用地址清理。

它编译，生成的软件运行。但是，当地址清理程序检测到错误时，我正在尝试获取核心转储，因为由于设置，这几乎是我可以从系统中获取信息的唯一方法。

我ASAN_OPTIONS=abort_on_error=1在命令行上调用该软件（使用 shell 脚本来执行此操作），并检查了它是否ulimit -c提供了无限的结果，但它不会产生核心转储。

我错过了什么？

这是在具有 gcc 版本 4.8.4 的 ubuntu 14.04 服务器上

编辑：sysctl kernel.core_pattern回馈kernel.core_pattern = |/usr/share/apport/apport %p %s %c %P. 这可能意味着启用了 apport（至少以某种形式）。但是，我已经能够从软件中的断言和 SIGFPE 中获得该系统上正确的核心文件（这就是怀疑数组溢出的原因）。

我正在尝试在我的 docker 容器中设置/修复 asan。为此，我使用了一个简单的示例程序

并编译它

使用 clang 4.0.1（我使用它没有区别-std）。

这会产生4.12.3-1-ARCH内核版本的错误，而我从谷歌或 asan FAQ 中提取的所有内容似乎都没有改变这一点。

gcc 版本是 5.4.0

我想像这样使用它：-fsanitize=address,leak

好的？

-fsanitize=address我在 centOS 7.2.1511 上编译了我的代码。当我将 gcc 更新到 7.1.0 时，它不能再生成核心转储文件了。有谁能够帮我？

gcc 编译选项：

链接选项：

当我使用 gcc 4.8.5 时，通常使用选项 ASAN_OPTIONS 生成核心转储，如下所示：

当我将 gcc 更新到 7.1.0 时，即使 ASAN_OPTIONS 像上面那样设置，也无法再生成核心转储。

我应该使用哪些 Asan 标志来检测更多错误？目前，我使用ASAN_OPTIONS=detect_stack_use_after_return=1.