Valgrind:可能丢失可以被视为绝对丢失吗? [英] Valgrind: can possibly lost be treated as definitely lost?

问题描述

我可以处理可能丢失"的 Valgrind memcheck 的输出吗?像肯定输了"?

Can I treat the output of a Valgrind memcheck, "possibly lost" as "definitely lost"?

可能丢失，或可疑":找到指向块内部的指针.指针最初可能指向开始和已经被移动了，或者它可能完全不相关.内存检查认为这样的块是可疑的"，因为不清楚是否指向它的指针仍然存在.

Possibly lost, or "dubious": A pointer to the interior of the block is found. The pointer might originally have pointed to the start and have been moved along, or it might be entirely unrelated. Memcheck deems such a block as "dubious", because it's unclear whether or not a pointer to it still exists.

肯定丢失，或泄露":最坏的结果是找不到指向块的指针.该块被归类为泄漏"，因为程序员不可能在程序中释放它退出，因为不存在指向它的指针.这很可能是一种症状在程序的某个较早点丢失了指针

Definitely lost, or "leaked": The worst outcome is that no pointer to the block can be found. The block is classified as "leaked", because the programmer could not possibly have freed it at program exit, since no pointer to it exists. This is likely a symptom of having lost the pointer at some earlier point in the program

推荐答案

是的，我建议将可能迷失与绝对迷失一样严重.换句话说，修复您的代码，直到完全没有丢失为止.

Yes, I recommend to treat possibly lost as severe as definitely lost. In other words, fix your code until there are no losts at all.

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

Possibly lost can happen when you traverse an array using the same pointer that is holding it. You know that you can reset the pointer by subtracting the index. But valgrind can't tell whether it is a programming error or you are being clever doing this deliberately. That is why it warns you.

#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 report

$ 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 将报告完全没有内存丢失.如果没有中止，指针将返回到数组的开头，内存将被正确freed.

If you remove abort() then Valgrind will report no memory lost at all. Without abort, the pointer will return to the beginning of the array and the memory will be freed properly.

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

This is a trivial example. In sufficiently complicated code it is no longer obvious that the pointer can and will return to the beginning of the memory block. Changes in other part of the code can cause the possibly lost to be a definitely lost. That is why you should care about possibly lost.

这篇关于Valgrind:可能丢失可以被视为绝对丢失吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！