c++ - 即使在修复泄漏后，Valgrind 仍显示相同的内存泄漏

Question

我们正试图找出在 Linux 上运行的 C++ 应用程序中的内存泄漏。我们正在使用 Valgrind 3.6.0，并且已经能够获得一些“绝对丢失”的堆栈。在报告中，它还给出了“肯定丢失”的字节总数。

我们必须包括的修复是这样的:将 delete ptr 更改为 delete[] ptr 其中 ptr 指向一个数组堆上的位置。

请注意，ptr 占用了大量内存。我们还以类似的方式修复了许多其他的缺失。因此，我们预计泄漏会减少。

但在修复之后，奇怪的是，Valgrind 在摘要中仍然报告了与以前相同数量的泄漏。

==00:00:15:13.661 14014== LEAK SUMMARY:
==00:00:15:13.661 14014==    definitely lost: 236 bytes in 8 blocks
==00:00:15:13.661 14014==    indirectly lost: 22,113 bytes in 17 blocks
==00:00:15:13.662 14014==      possibly lost: 695,006 bytes in 47 blocks
==00:00:15:13.662 14014==    still reachable: 2,056,059 bytes in 732 blocks
==00:00:15:13.662 14014==         suppressed: 0 bytes in 0 blocks

有人可以阐明 Valgrind 的这种行为吗？我们正在使用所有正确的选项来调用 mem_check 工具等。

Answer 1

答案是用错误的delete 释放的 block 从来没有包含在泄漏报告中，因为 valgrind 意识到错误的排序delete 被使用并报告并释放了整个 block 。

我们可以通过一个简单的程序看到这个效果:

int main(int argc, char **argv)
{
  int *x = new int[20];

  delete x;

  return x != 0;
}

当在 valgrind 下运行时，报告:

==12212== Mismatched free() / delete / delete []
==12212==    at 0x61DCD1FC: operator delete(void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12212==    by 0x4005AC: main (x.c:7 in /tmp/x)
==12212==  Address 0x61fd4040 is 0 bytes inside a block of size 80 alloc'd
==12212==    at 0x61DCD967: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==12212==    by 0x40059C: main (x.c:5 in /tmp/x)
==12212== 
==12212== 
==12212== HEAP SUMMARY:
==12212==     in use at exit: 0 bytes in 0 blocks
==12212==   total heap usage: 1 allocs, 1 frees, 80 bytes allocated
==12212== 
==12212== All heap blocks were freed -- no leaks are possible

所以它已经告诉您正在使用错误类型的 delete 但随后报告没有泄漏，因为它实际上在意识到您的错误后释放了整个 block 。

它报告为泄漏的东西是你根本没有尝试释放的东西，如果你阅读了应该在泄漏摘要之前的泄漏报告，那么 valgrind 会准确地告诉你所有泄漏内存的分配位置，您应该能够追踪这些泄漏并修复它们。