valgrind - 在共享库中查找内存泄漏答案

【问题标题】：valgrind - Find memory leak in a shared libraryvalgrind - 在共享库中查找内存泄漏
【发布时间】：2012-09-19 05:47:20
【问题描述】：

我需要知道如何找出共享库中的内存泄漏，该共享库将被加载到发布二进制文件中。我的意思是我使用 -g 选项构建的共享库，但加载共享库的二进制文件不是使用 -g 选项构建的。

我得到的泄漏报告如下。

==739==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==739==    by 0x84781B1: ???
==739==    by 0x87507F5: ???
==739==    by 0x874CF47: ???
==739==    by 0x874E657: ???
==739==    by 0x874F7C2: ???
==739==    by 0x8779C0C: ???

请告诉我如何从共享库中获取泄漏的堆栈跟踪？

【问题讨论】：

我发布这个是为了帮助那些挣扎的人？？（问号）在他们的 valgrind 输出中 - 确保您尝试不同版本的 valgrind。我使用了不同版本的 valgrind 和所有这些？消失了。

标签： memory-leaks shared-libraries valgrind

【解决方案1】：

假设泄漏确实来自您的共享库，那么我认为问题不在于主可执行文件中缺乏调试。

您的问题更有可能是可执行文件在完成之前通过调用dlclose 来卸载共享库。这意味着当 valgrind 来检查泄漏时，库的所有符号信息都消失了，因为不再加载库。

如果您可以重建可执行文件，那么最简单的解决方案可能是暂时停止调用dlclose，以便库保持加载直到结束。

如果您不能这样做，请尝试使用LD_PRELOAD 来保持库的加载状态，如下所示：

LD_PRELOAD="/path/to/library.so" valgrind my-executable

这有望诱使动态链接器在库关闭后仍保持加载状态。

【讨论】：

有一个补丁提供了在 dlclose 后禁用符号卸载的选项。该补丁有效，我已经使用过很多次。但是补丁是旧版本的，我想它现在已经烂了。 bugs.kde.org/show_bug.cgi?id=79362
@TomH：让我指出，“省略 dlclose”解决方法会导致大量误报。如果堆栈上有对象破坏了堆上的元素，那么这些在输出中显示为泄漏，因为 dlclose 会首先完成破坏。
如果 valgrind 是 64 位，第二个也不能正常工作，但你调试的是 32

【解决方案2】：

正如前面的答案所暗示的，这是因为您在程序终止之前关闭了库，因此 valgrind 无法使用符号信息。

使用 LD_PRELOAD 对我不起作用；我现在有两个版本；一个明确不调用 dlclose();在这个版本中，valgrind 正确地报告行号信息，正如您对动态链接所期望的那样。

【讨论】：