Valgrind 是否存在已知的误报问题？

Question

Valgrind 是否存在任何已知的误报？我使用

fmemopen

函数得到“条件跳转或移动取决于未初始化的值”，用 C 编写并使用 GCC 编译。我能确定这是真的吗？

编辑：是否存在抑制文件中未包含的已知问题？是否有人可以在程序中做一些事情，这些事情并不是真正的错误，但 Valgrind 会说它们是错误？如果存在已知问题，最好有一个列表。

Answer 1

是的，Valgrind 存在误报，这就是为什么它有针对特定 glibc 和 gcc 版本的抑制文件的原因。如果您将较旧的 valgrind 与较新的 gcc 和 glibc 一起使用，即 valgrind 3.3 与 glibc 2.9 一起使用，则可能会出现误报。

话虽如此，您仍然需要调查问题并找出它是否真的是误报（如果事实证明是这样，您可以自己编写抑制）或者它是否是您程序中的真正错误.

没有快速简单的方法来说明这里发生了什么，但在这种情况下，我怀疑您正在将未初始化的值从代码传递到库代码。尝试 Valgrind 选项

--track-origins=yes

。 它将显示未初始化值的来源。如果这是您的代码，也许您应该初始化它。如果它在库内部，则可能是误报，或者库调用参数的错误值仍然可能导致它，因此请检查这些。

Answer 2

Valgrind 带有一些默认的错误抑制功能，但它们绝不涵盖所有库。

错误检查工具可以检测基础库中的许多问题，例如预装在 GNU/Linux 系统上的 GNU C 库和 X11 客户端库。您无法轻松修复这些错误，但您不想看到这些错误（是的，有很多错误！）因此 Valgrind 会在启动时读取要抑制的错误列表。系统构建时，./configure 脚本会创建默认的抑制文件。

您可以创建自己的错误抑制，您知道这些与您的代码无关。

Answer 3

Debian SSL 的开发难道不是因为用 Valgrind 修复一些误报吗？

Answer 4

我以 Valgrind 开发人员的身份回答这个问题。

我不断在此处和 Reddit 上看到评论称 memcheck 会产生误报。 99.9% 的情况是因为开发人员不知道真正的原因并且存在确认偏差并希望相信他们的代码是正确的。

也就是说，memcheck 会产生一些误报

1. 有几个 bugzilla 项目因逻辑和操作的编译器优化而导致错误，其中编译器可以交换操作数的顺序。如果正确的操作数是指向未初始化的堆栈内存的指针，则可能会导致误报。使用 C++ std::Optional 时似乎会发生这种情况。
2. 系统调用参数验证。如果使用的结构有孔或填充，可能会产生错误。这是一个灰色地带。我们无法区分洞和场，所以这个错误可能是无害的。 Valgrind 确实抑制了一些常见的情况。您需要了解您的代码并决定是否抑制或将内存设置为零。
3. 虚拟化环境。如果您使用 Docker 或 WSL，它们对真实计算机的表现并不完美，可能会产生错误。我的建议是避免 WSL。 VMware 和 VirtualBox 还可以，但仍不完美。 Docker 比 WSL 好，但不如 vbox 和 VMware。