5

Look something strange on my mac :

$> cat main.c
#include <stdio.h>   
int main(int ac, char **av) {
    for (int i = 0; i < ac; i++)
        printf("%s\n", av[i]);
    return 0;
}
$> gcc main.c -std=c99
$> valgrind ./a.out hello my friends

And here is the result :

==725== Memcheck, a memory error detector
==725== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==725== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==725== Command: ./a.out hello my friends
==725== 
--725-- ./a.out:
--725-- dSYM directory is missing; consider using --dsymutil=yes
./a.out
hello
my
friends
==725== 
==725== HEAP SUMMARY:
==725==     in use at exit: 6,146 bytes in 33 blocks
==725==   total heap usage: 33 allocs, 0 frees, 6,146 bytes allocated
==725== 
==725== LEAK SUMMARY:
==725==    definitely lost: 0 bytes in 0 blocks
==725==    indirectly lost: 0 bytes in 0 blocks
==725==      possibly lost: 0 bytes in 0 blocks
==725==    still reachable: 6,146 bytes in 33 blocks
==725==         suppressed: 0 bytes in 0 blocks
==725== Rerun with --leak-check=full to see details of leaked memory
==725== 
==725== For counts of detected and suppressed errors, rerun with: -v
==725== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1)

If someone knows why, and could explain me where does theses leaks come from, I'd be thankful !!

Have a good day :-)

DCMaxxx
  • 2,534
  • 2
  • 25
  • 46
  • Re-run with `--leak-check=full`. You'll probably see that the allocations are system stuff done by your environment (one-off startup/initialization things) that aren't really leaks. – Mat Dec 18 '11 at 09:34
  • 1
    Did you "Rerun with --leak-check=full to see details of leaked memory" as suggested by the valgrind output message? – bobbymcr Dec 18 '11 at 09:34

2 Answers2

9

These aren't leaks. Objects listed as still reachable shouldn't trouble you. If you'd have a non-zero value in the rows above then it should ring an alarm bell though!

Those 33 blocks listed as still reachable are most probably some blocks allocated inside printf calls by your standard library. Nothing to be worried about.

Consider also taking a look at this answer to a similar question.

Community
  • 1
  • 1
Jan
  • 11,636
  • 38
  • 47
3

"still reachable" when a program has terminated is really nothing to worry about.

"still reachable" means that there are allocated memory which hasn't been released, but there are still pointers pointing towards this memory. Therefor valgrind doesn't flag it as a true memory "leak".

It's often a waste of time to spend time free:ing the allocated memory before a application ends, the allocated memory will be returned to the OS anyhow since the application is terminating.

Filip Roséen - refp
  • 62,493
  • 20
  • 150
  • 196
  • In my experience, trying to free all objects correctly at the end of your run is important. I've found a lot of bugs that way. It's true that the gravity of the supposed 'leak' is minimal, but the exercice in correctness it imposes has wide repercutions. On big projects it can make a real difference. It actually did on the 2 big projects (500K and 150K lines of C) I worked on. – Patrick Schlüter Dec 18 '11 at 11:33