实施例

Question

我可以将Valgrind memcheck的输出“可能丢失”视为“绝对丢失”吗？

可能丢失或“可疑”：找到指向块内部的指针。指针最初可能指向了开头和   已被移动，或者可能完全不相关。 MEMCHECK   认为这样一个块“可疑”，因为不清楚是否一个   指向它的指针仍然存在。

绝对丢失或“泄露”：最糟糕的结果是找不到指向该块的指针。该区块被归类为“泄露”，   因为程序员不可能在程序中释放它   退出，因为没有指向它的指针。这可能是一个症状   在程序的某个早期点失去了指针

Answer 1

是的，我建议将可能丢失的视为绝对丢失。换句话说，修复你的代码直到完全没有丢失。

当您使用持有它的相同指针遍历数组时，可能会发生丢失。您知道您可以通过减去索引来重置指针。但是valgrind无法判断这是编程错误还是你是~~聪明地~~故意这样做。这就是它警告你的原因。

实施例

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

int main(int argc, char** argv) {
  char* s = "string";
  // this will allocate a new array
  char* p = strdup(s);
  // move the pointer into the array
  // we know we can reset the pointer by subtracting
  // but for valgrind the array is now lost
  p += 1;
  // crash the program
  abort();
  // reset the pointer to the beginning of the array
  p -= 1;
  // properly free the memory for the array
  free(p);
  return 0;
}

编译

$ gcc -ggdb foo.c -o foo

Valgrind报告

$ valgrind ./foo
...
==31539== Process terminating with default action of signal 6 (SIGABRT): dumping core
==31539==    at 0x48BBD7F: raise (in /usr/lib/libc-2.28.so)
==31539==    by 0x48A6671: abort (in /usr/lib/libc-2.28.so)
==31539==    by 0x10917C: main (foo.c:14)
==31539== 
==31539== HEAP SUMMARY:
==31539==     in use at exit: 7 bytes in 1 blocks
==31539==   total heap usage: 1 allocs, 0 frees, 7 bytes allocated
==31539== 
==31539== LEAK SUMMARY:
==31539==    definitely lost: 0 bytes in 0 blocks
==31539==    indirectly lost: 0 bytes in 0 blocks
==31539==      possibly lost: 7 bytes in 1 blocks
==31539==    still reachable: 0 bytes in 0 blocks
==31539==         suppressed: 0 bytes in 0 blocks

...

如果您删除abort()，那么Valgrind将报告根本没有丢失内存。如果没有中止，指针将返回到数组的开头，内存将正确free。

这是一个微不足道的例子。在足够复杂的代码中，指针可以并且将返回到存储器块的开头不再明显。代码其他部分的更改可能导致可能丢失成为肯定丢失。这就是为什么你应该关心可能丢失。

Valgrind：可能会失去被视为绝对失败的对待？

1 个答案:

实施例