使用海湾合作委员会进行消毒，导致意外提前退出

fsanitize with gcc causing unexpected early exit

本文关键字：意外 退出 用海 委员会      更新时间：2023-10-16

我有一个错误，在无效堆指针上调用free()时，该错误无法始终重现。 用有问题的代码从根本上说，将这个问题减少到"最小"是不可能的——(一旦我这样做了，它就解决了(。 我无法发现任何明显的问题(例如从未调用calloc的潜在情况，或双重免费等......

我相信valgrind可以解决这个问题，除了性能影响太极端(这些是超时的客户端>服务器调用，以及开始时成本高昂的操作......在某些情况下需要>4 秒(

这让我fsanitize=address，我相信吗？ 到目前为止，我的经验是...不是很好。

我得到的是两个静态库和一个与它们链接的可执行文件。 我已经为他们三个打开了fsanitize=address。 使用-fsanitize=address，代码在经过非常彻底测试和正确的初始化例程期间(在 256 字节memcpy到 16 meg 堆分配的中间(在调试器下干净地退出 - 退出代码 1(。

任何有使用fsanitize实践经验的人都可以为我提供任何关于问题可能出在哪里的提示吗？ 我在 cmake 下使用 gcc/ld，代码(基本上(是用 C++ 编译的 C。 切换到 clang 可能是一种选择，如果这可能会改善事情。

文件的典型编译命令：

"command": "/usr/bin/c++   -I. -I/home/redacted -fpermissive -g -g3 -fasynchronous-unwind-tables -fsanitize=address   
-std=gnu++11 -o core/CMakeFiles/nginx_core.dir/src/core/nginx.cpp.o -c /home/redacted.cpp",

我只是把它留在这里，供将来有fsanitize问题的搜索者使用。 TLDR;--它奏效了。 我有两个基本问题：

  1. fsanitize 正在输出有关其退出原因的全面错误信息。 这被nginx吞下了...在我们的自定义版本中，它被重定向到一个模糊的日志文件。 不知道为什么在gdb下我没有调试中断，但尽管如此......它正在检测到一个合法的错误。 此处的关键信息：在__asan_report_error中设置断点将在退出之前停止程序，以便您可以检查各种帧。

  2. 虽然初始化例程是正确的并且经过了大量测试，但正如我所提到的，它确实要求其客户端正确分配(非平凡的(配置结构。 在这种情况下，结构距离完成少 1 个字节，导致 1 个字节过度读取。

相关文章：