C - Valgrind在Mac上向linux显示不同的结果？

Question

这是一个非常简单的程序，我写的是为了显示Mac（El Capitan）和Linux Mint 17.2上的valgrind输出之间的差异。

有没有办法在Mac上获得相同类型的输出？我不明白为什么它在Mac上显示比在Linux上更多的堆使用？

出于一个奇怪的原因 Linux Mint显示正在释放的内存，而 OSX不

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char const *argv[]) {

  char *str = (char *)malloc(15);
  strcpy(str, "Hello World!");
  printf("%s\n", str);
  free(str);
  return 0;
}

Linux Mint 17.2 to a thread I found on google code

Mac OSX El Capitan

Answer 1

C标准库和运行时在调用main之前执行操作，printf也在内部执行操作。这个＆＃34;东西＆＃34;可能包括内存分配。这是特定于实现的，因此完全不同的实现显示不同的分配量并不奇怪。

然后，当程序退出时，实际上可能不需要free任何堆分配，因为当进程终止时，堆将消失，poof，由OS删除（在如上所述的桌面操作系统中）。应用程序代码应该释放它分配的所有内存（因为可移植性，因为那时你实际上可以使用像 valgrind 这样的工具，因为它可以＆＃34;＆＃34;清洁＆＃34）。但是对于平台和编译器特定的库代码，它只会减慢每个程序的退出速度，没有任何好处。因此，库不执行它基本上是一种优化，您通常不应该在自己的程序中执行（除非您可以实际测量它在某处产生影响）。

因此，像 valgrind 这样的工具通常包含已知未释放内存块的抑制列表。您还可以为您使用的任何库配置自己的抑制列表，并在程序退出时不释放所有内存。但是在处理抑制时，最好确保你压制安全的情况，而不是隐藏实际的内存泄漏。

推测：因为这里分配数量的差异非常大，人们可能会猜测，Linux实现只使用静态/全局变量，其中Mac实现也使用堆分配。存储在那里的实际数据可能包括stdin / stdout / stderr缓冲区之类的东西。现在这只是一个猜测，我没有检查源代码，但目的是让我们知道可能需要的分配。

Answer 2

您需要了解如何解释结果，尤其是在Mac OS X上。

你的Mac输出说（我希望我没有输入这个 - 该死，屏幕图像真是太痛苦了！）：

definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
  possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
     suppressed: 26,091 bytes in 184 blocks

这意味着它说 - 你没有内存泄漏。被抑制的东西来自Mac C运行时库启动代码。它分配了相当多的空间（大多数26 KiB在你的机器上，有184个单独的分配）并且在程序执行之前没有明确释放它。这就是为什么他们被压制 - 他们不是你的程序的错，而且你基本上没有什么可以做的。这就是Mac上的生活方式。 FWIW，我刚刚运行了我的一个程序并得到了：

==57081== 
==57081== HEAP SUMMARY:
==57081==     in use at exit: 38,858 bytes in 419 blocks
==57081==   total heap usage: 550 allocs, 131 frees, 46,314 bytes allocated
==57081== 
==57081== LEAK SUMMARY:
==57081==    definitely lost: 0 bytes in 0 blocks
==57081==    indirectly lost: 0 bytes in 0 blocks
==57081==      possibly lost: 0 bytes in 0 blocks
==57081==    still reachable: 0 bytes in 0 blocks
==57081==         suppressed: 38,858 bytes in 419 blocks
==57081== 
==57081== For counts of detected and suppressed errors, rerun with: -v
==57081== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

我不知道为什么我有比运行时系统多12个KiB的空间和235个分配。但是，这绝对是Mac上的正常行为。

如果对o / s进行了重大升级，那么旧的抑制可能会停止生效，你可能会突然得到更多“仍然可以”或其他内存“问题”;此时，您仔细检查报告，然后生成新的抑制。我有一个有84个抑制的文件，我曾经在其中使用过 - 然后我得到了Valgrind的新版本，它们已经到位了。