问题标签 [ubsan]

我想抑制第三方库中的一个错误，但在任何其他失败的检查中仍然让程序退出 1。在我看来，无论文件的内容如何，-fno-sanitize-recover​​都会退出程序。另一方面，指定的错误被正确抑制，另一个错误仍然打印，但程序正常退出，这是我不想要的suppressions。-fsanitize-recover

我怎样才能达到预期的行为？Ubsan 抑制和 -fno-sanitize-recover 真的相互排斥吗？

在地址清理程序的文档（https://releases.llvm.org/7.0.0/tools/clang/docs/AddressSanitizer.html）中，它指出：

链接共享库时，AddressSanitizer 运行时没有链接，所以 -Wl,-z,defs 可能会导致链接错误

这似乎不仅适用于 ASAN，也适用于 UBSAN。这对 UBSAN 来说特别不方便，因为vptrsanitizer 可以在库之间引入新的 typeinfo 依赖项（https://jira.mongodb.org/browse/SERVER-49798中有很多细节）。

我真的更喜欢-Wl,-z,defs为我们的 UBSAN 构建构建。实际上，就编译过程而言，我实际上可以使用 ubsan 构建来完成这项工作，方法是手动将诸如此类的内容注入-lclang_rt.ubsan_standalone-x86_64共享库的链接行。

但这给我留下了一个烦人的问题：为什么clang链接驱动程序在链接共享库时不根据显式文档自动执行此操作？它显然可以做到这一点，因为它已经为自动获取运行时的程序做到了。它明确没有让我怀疑这样做是否有问题。

• 出于某种原因，将运行时库强制ubsan到所有共享库的链接线上是一个坏主意吗？
• 它是否会以某种方式破坏消毒剂的有效性？
• 还有其他一些我没有看到的可怕的缺点吗？

我有一个 UndefinedBehaviorSanitizer 构建 ( -fsanitize=undefined)，并且我试图在我无法控制的外部库中抑制 UB 的警告。clang/gcc 文档提到__attribute__((no_sanitize("undefined")))了 ，但令我惊讶的是，这个属性似乎并没有抑制来自子例程的警告。

简单的例子：

由于此属性似乎不起作用，我该如何抑制此警告？我可以从我的 UBSan 构建中删除整个目标，但这似乎非常严厉。

我在这里有一个小单元测试，它有未定义的行为。

源代码：

我在我的 CMakeLists.txt 中启用了 UBSAN：

UBSAN 正确识别未定义的行为：

但是，我的测试仍然通过。

当 UBSAN 发现问题时，是否可以触发测试失败（抛出异常、退出 1 等）？

我想为我的一个启用未定义行为清理的存储库构建一个测试程序（至少使用 GCC，也许还有 clang）。我知道如何手动执行此操作：

• 添加-fsanitize=undefined到编译标志
• 添加-lubsan到链接标志
• 确保安装了适当的版本libubsan。

现在，在 CMake 中，我希望以下内容可以正常工作：

...但没有这样的版本（从 CMake 3.21.0-rc2 开始）。那么，我该怎么做呢？从某个地方获取 FindUBSan.cmake？也许做点别的？

PS - 这个问题同样适用于 C

考虑以下 C 程序：

该程序具有未定义的行为，因为 INT_MIN 的否定是不可表示的；或者，成为一名语言律师——因为 C 标准是这样说的。

现在，编译器知道或者可以知道，情况就是这样。然而 - GCC 和 clang 都没有对此发出警告，即使使用-W -Wall -Wextra(GodBolt); 只有清理未定义的行为才能捕获它 - 在运行时。

为什么会这样？通常，试图证明 UB 发生在编译时是否成本太高，所以编译器不会打扰？

在最近的一个项目中，我测试了不同编译器标志和消毒剂的组合，以评估调试我的 C 代码的相关性。通过测试这些组合的影响，我偶然发现了一种我不理解的行为。

复制器

我使用一个包含内存泄漏的小型 hello-world 代码示例来触发地址清理程序（ASAN）：

观察

我使用了编译器和链接器标志的不同组合，有时我观察到地址清理程序报告了 memleak，而在其他情况下它没有报告 memleak。我已经消除了所有潜在的编译器标志，直到找到影响 ASAN 报告或忽略内存泄漏的最小标志集：

ASAN 会在使用命令编译时报告内存泄漏

ASAN 使用命令编译时不会报告内存泄漏

然而

我观察到相同的行为，与使用 GCC 或 clang 无关。因此，我担心这不是由不同消毒剂、优化级别和标志之间的意外干扰引起的错误，-fno-omit-frame-pointer而是由于我缺乏知识，我无法理解的预期行为的影响-fno-omit-frame-pointer是什么。

如果有人可以总结什么-fno-omit-frame-pointer/做了什么-fomit-frame-pointer以及它在哪些情况下起作用，或者解释这个标志对给定示例的影响，或者指出我可以找到这些信息的地方，我将不胜感激。

为了完整性

我正在使用 Arch-linux 并运行以下版本的软件：

• gcc 11.1.0-1
• 铿锵声13.0.0-2
• glibc 2.33-5

但是，我刚刚测试并验证了示例和观察结果也适用于gcc:bullseye来自 docker-hub 的 linux/amd64 的 docker 映像。

像 libstdc++ 一样，我们在某些地方检查abi::__forced_unwind，然后重新抛出它，而不是采取其他行动。像 libstdc++ 一样，我们通过引用来捕获它：

但是如果我们真的 pthread_cancel 来执行代码，ubsan 会抱怨：

运行时错误：引用绑定到“struct __forced_unwind”类型的空指针

在这里，我们是通过 const-ref 还是通过 mutable ref 捕获并不重要。

我们（和 libstdc++）是否真的在这里遇到了 UB，或者它是 GCC 的 UBSan 实现中的误报？