Valgrind showing memory leak for printf and unused

2019-01-12 09:17发布

问题:

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

int main(int argc, char *argv[]){
  char *str = malloc(sizeof(char)*5);
  str = strcpy(str, "test");
  printf("%s\n", str);
  free(str);
  return 0;
}

When I use Valgrind on my Mac (OS X, 10.9.5) I get the following message:

==77215== HEAP SUMMARY:
==77215==     in use at exit: 29,211 bytes in 374 blocks
==77215==   total heap usage: 451 allocs, 77 frees, 35,160 bytes allocated
==77215== 
==77215== 4,096 bytes in 1 blocks are still reachable in loss record 76 of 76
==77215==    at 0x66CB: malloc (in /usr/local/Cellar/valgrind/3.10.0/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==77215==    by 0x182855: __smakebuf (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x197217: __swsetup (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x1B0158: __v2printf (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x1B06AF: __xvprintf (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x187B29: vfprintf_l (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x18596F: printf (in /usr/lib/system/libsystem_c.dylib)
==77215==    by 0x100000F2B: main (test.c:8)
==77215== 
==77215== LEAK SUMMARY:
==77215==    definitely lost: 0 bytes in 0 blocks
==77215==    indirectly lost: 0 bytes in 0 blocks
==77215==      possibly lost: 0 bytes in 0 blocks
==77215==    still reachable: 4,096 bytes in 1 blocks
==77215==         suppressed: 25,115 bytes in 373 blocks
==77215== 
==77215== For counts of detected and suppressed errors, rerun with: -v
==77215== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)

Does printf allocate memory by itself? If I remove the printf I only get the following:

==77237== HEAP SUMMARY:
==77237==     in use at exit: 25,115 bytes in 373 blocks
==77237==   total heap usage: 450 allocs, 77 frees, 31,064 bytes allocated
==77237== 
==77237== LEAK SUMMARY:
==77237==    definitely lost: 0 bytes in 0 blocks
==77237==    indirectly lost: 0 bytes in 0 blocks
==77237==      possibly lost: 0 bytes in 0 blocks
==77237==    still reachable: 0 bytes in 0 blocks
==77237==         suppressed: 25,115 bytes in 373 blocks
==77237== 
==77237== For counts of detected and suppressed errors, rerun with: -v
==77237== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 15)

Where does the 373 blocks come from?

回答1:

Until the Valgrind team prioritizes OS X, you can safely assume that it will not give correct results on Apple systems running OS X versions newer than 10.7.

On my Mavericks (10.9.5) machine, I still get the following warning from Valgrind (3.9.0)

WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.

For what it's worth, Valgrind 3.10.0 shows no leaks on my Debian Jessie installation.



回答2:

It isn't telling you that there is a leak:

==77215== LEAK SUMMARY:
==77215==    definitely lost: 0 bytes in 0 blocks
==77215==    indirectly lost: 0 bytes in 0 blocks
==77215==      possibly lost: 0 bytes in 0 blocks
==77215==    still reachable: 4,096 bytes in 1 blocks
==77215==         suppressed: 25,115 bytes in 373 blocks

it's telling you that there is a block which is still reachable; whether or not there is a leak is dependent on your definition of 'leak'. What it does mean is that there is a pointer to the block somewhere.

Refer to Still Reachable Leak detected by Valgrind for more information.



标签: c valgrind