Valgrind 报告 OS X 10.8.1 内存泄漏答案

【问题标题】：Valgrind reports leaked memory on OS X 10.8.1Valgrind 报告 OS X 10.8.1 内存泄漏
【发布时间】：2012-09-17 02:36:23
【问题描述】：

我在 OS X 10.8.1，Mountain Lion 上使用 Valgrind 3.8.0 版。关于与 10.8.1 的兼容性，Valgrind's site 说（我的斜体字）：

Valgrind 3.8.0 适用于 {x86,amd64}-darwin（Mac OS X 10.6 和 10.7，对 10.8 的支持有限）。

那么，我知道 10.8.1 只有“有限支持”。尽管如此，this bug report 说（我的斜体字）：

这个（最新的 3.8.0 版本） 使得 Valgrind 编译并能够在 OSX 10.8 上运行小程序。但是请注意它仍然断言更大的应用程序，而 32 位程序不是完全正确检查（Memcheck 遗漏了大多数错误）。

好的，没关系。所以 Valgrind 应该可以在 10.8.1 上工作，如果有气质的话。所以现在我的问题：

我能够在 10.8.1 上轻松编译 Valgrind，但是当我在几个小型 C 程序上运行它时，我看到了一些奇怪的结果。为了尽量减少问题的可能原因，我最终编写了以下“程序”：

int main () {                                                               
    return 0;
}

我会说，这不是很令人兴奋，而且几乎没有错误的空间。然后，我通过 Valgrind 编译并运行它：

gcc testC.c
valgrind ./a.out

这是我的输出：

==45417== Command: ./a.out
==45417== 
==45417== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==45417== WARNING: Expect incorrect results, assertions and crashes.
==45417== WARNING: In particular, Memcheck on 32-bit programs will fail to
==45417== WARNING: detect any errors associated with heap-allocated data.
==45417== 
--45417-- ./a.out:
--45417-- dSYM directory is missing; consider using --dsymutil=yes
==45417== 
==45417== HEAP SUMMARY:
==45417==     in use at exit: 58,576 bytes in 363 blocks
==45417==   total heap usage: 514 allocs, 151 frees, 62,442 bytes allocated
==45417== 
==45417== LEAK SUMMARY:
==45417==    definitely lost: 8,624 bytes in 14 blocks
==45417==    indirectly lost: 1,168 bytes in 5 blocks
==45417==      possibly lost: 4,925 bytes in 68 blocks
==45417==    still reachable: 43,859 bytes in 276 blocks
==45417==         suppressed: 0 bytes in 0 blocks
==45417== Rerun with --leak-check=full to see details of leaked memory
==45417== 
==45417== For counts of detected and suppressed errors, rerun with: -v
==45417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

我知道 Valgrind 还没有准备好迎接 10.8.1 的黄金时段。尽管如此，我还是希望能够在这里使用它——我只需要在小程序上使用它，而且对于即时的结果来说，没有什么是关键任务。但很明显，它报告了一个似乎不太可能泄漏的程序中的大量泄漏。因此：

我应该怎么做才能解决这个问题？

其他信息：

添加一个故意泄露的整数确实将“肯定丢失”的计数增加了相应的 4 个字节。
同样，通过不释放内存而故意泄漏对 malloc 的调用确实适当地增加了堆分配计数。
使用 -g 标志编译然后运行到 Valgrind（以解决 dSYM directory is missing 错误）确实会导致该错误消失，但不会改变大量内存泄漏的问题报告。

【问题讨论】：

我得到了同样的结果。
这已经过时了。 2017 年，Valgrind 抑制了大多数误报。
@FranklinYu 它是否抑制了 10.8.1 上的大多数误报？如果是这样，请写下该效果的答案，我会将其标记为已接受。
@ravron 对不起，不（或者至少我不知道）。我只在 10.11 中测试过。我想说这个问题可能取决于 OS X 的版本。但你可能仍然想尝试使用最新的 Valgrind，因为他们do suppress several (if not most) false positives on 10.8。从您的日志suppressed: 0 bytes in 0 blocks 中得知，它过去不会抑制任何误报。所以至少它得到了改进。

标签： c memory-leaks valgrind osx-mountain-lion

【解决方案1】：

它会告诉你：

预期不正确的结果、断言和崩溃。

如果您仍想运行它，请打印有关虚假泄漏 (--leak-check=full) 的详细信息，并将其用于 suppress 有关它们的消息。

【讨论】：

我担心这可能是答案。我会继续这样做。谢谢。

【解决方案2】：

Valgrind 树干似乎已经改进到现在可以使用的程度。我还没有看到它崩溃，但确实有很多误报，可以使用抑制文件来处理。

现在，我的抑制文件如下所示：

# OS X 10.8 isn't supported, has a bunch of 'leaks' in the loader
{
   osx_1080_loader_false_positive_1
   Memcheck:Leak
   ...
   fun:_ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
   ...
}
{
   osx_1080_loader_false_positive_2
   Memcheck:Leak
   ...
   fun:_ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
   ...
}
{
   osx_1080_loader_false_positive_3
   Memcheck:Leak
   ...
   fun:map_images_nolock
   ...
}
{
   osx_1080_loader_false_positive_4
   Memcheck:Leak
   ...
   fun:_objc_fetch_pthread_data
   fun:_ZL27_fetchInitializingClassLista
   fun:_class_initialize
   fun:_class_initialize
   fun:_class_initialize
   fun:_class_initialize
   fun:prepareForMethodLookup
   fun:lookUpMethod
   fun:objc_msgSend
   fun:_libxpc_initializer
   fun:libSystem_initializer
}

【讨论】：

【解决方案3】：

我还在 mac osx 10.8 上从 macports 运行 valgrind。它运行时不会崩溃，但确实会产生一些疯狂的结果，就像这篇 stackoverflow 帖子 Confusing output from Valgrind shows indirectly lost memory leaks but no definitely lost or possibly lost 中的结果一样。

【讨论】：