5

我在 OS X 10.8.1、Mountain Lion 上使用 Valgrind 3.8.0 版。关于与 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;
}

我会说，这不是很令人兴奋，而且几乎没有错误的空间。然后，我编译并通过 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错误）确实会导致该错误消失，但不会改变报告大量内存泄漏的问题。
4

3 回答 3

6

它在那里告诉你：

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

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

于 2012-09-17T05:09:26.290 回答
6

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
}
于 2013-01-22T18:07:13.057 回答
0

我还在 mac osx 10.8 上从 macports 运行 valgrind。它运行时不会崩溃，但确实会产生一些疯狂的结果，就像这个 stackoverflow 帖子中的结果一样，Valgrind 的混淆输出显示间接丢失的内存泄漏，但没有绝对丢失或可能丢失。

于 2014-03-26T21:09:14.043 回答