Valgrind报告在OS X 10.8.1上存在内存泄漏问题。

Question

我正在使用Valgrind 3.8.0版本在OS X 10.8.1 Mountain Lion上。关于与10.8.1兼容性的问题，Valgrind网站上表示 (下面是斜体部分)： Valgrind 3.8.0适用于{x86、amd64}-darwin(Mac OS X 10.6和10.7)，对于10.8提供了有限的支持。

我知道，在10.8.1上只有“有限的支持”。然而，这份错误报告(下面是斜体部分)表示：

这个(最新的3.8.0版本)使得Valgrind在OSX 10.8上编译并能够运行小程序。但是请注意，它仍然会因大型应用程序发生断言，并且32位程序根本没有被正确检查(许多错误被Memcheck忽略)。

好吧，那就没事了。因此，Valgrind在10.8.1上应该可以工作，尽管有点难预测。现在我的问题是：

我成功地将Valgrind编译到了10.8.1上，并在几个小的C程序上运行时看到了一些奇怪的结果。为了尝试减少问题的可能原因，我最终编写了以下“程序”:

int main () {                                                               
    return 0;
}

我认为这并不是非常令人兴奋, 而且出现bug的空间很小。接着，我使用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目录不存在”错误）确实会使该错误消失，但并未改变报告大量内存泄漏的问题。

- ravron

---

我得到了相同的结果。 - Pritesh Acharya

这已经过时了。在2017年，Valgrind抑制了大多数误报。 - Franklin Yu

@FranklinYu，它是否能够抑制10.8.1上的大多数误报？如果是，请写一个回答以表明我会标记它为已接受。 - ravron

@ravron 抱歉，没有（或者至少我不知道）。我只在10.11上进行了测试。我想说这个问题可能取决于OS X的版本。但是你仍然可以尝试使用最新的Valgrind，因为它们确实抑制了10.8上的几个（如果不是大多数）误报。它以前不会抑制任何误报，从你的日志中已知suppressed: 0 bytes in 0 blocks。所以至少有所改进。 - Franklin Yu

Answer 1

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
}

- leecbaker

Answer 2

这里面已经告诉你了：

预计会出现不正确的结果、断言和崩溃。

如果你仍然想运行它，请打印关于虚假泄漏的详细信息（--leak-check=full），并使用它来忽略有关它们的消息。

- n. m.

---

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

Answer 3

我也在Mac OS X 10.8上使用MacPorts运行Valgrind。它可以正常运行，但会产生一些疯狂的结果，就像这个stackoverflow帖子中的那些一样，Confusing output from Valgrind shows indirectly lost memory leaks but no definitely lost or possibly lost。

- Zachary Kraus