Valgrind and Memory Leaks

6
votes

I'm doing a little bit of memory profiling to my software and after running standard memory leak check with valgrind's following command

valgrind --tool=memcheck --leak-check=full ./path_to_program

I got following summary:

==12550== LEAK SUMMARY:

==12550== definitely lost: 597,170 bytes in 7 blocks

==12550== indirectly lost: 120 bytes in 10 blocks

==12550== possibly lost: 770,281 bytes in 1,455 blocks

==12550== still reachable: 181,189 bytes in 2,319 blocks

==12550== suppressed: 0 bytes in 0 blocks

==12550== Reachable blocks (those to which a pointer was found) are not shown.

==12550== To see them, rerun with: --leak-check=full --show-reachable=yes

==12550==

==12550== For counts of detected and suppressed errors, rerun with: -v

==12550== ERROR SUMMARY: 325 errors from 325 contexts (suppressed: 176 from 11)

It doesn't look quite good to me, so my question is

Why isn't my program exploding if it has all these leaks?

And also what is the difference between:

  • definitely lost
  • indirectly lost
  • possibly lost
  • still reachable

and how can I try to fix them?

1
c++memory-leaksvalgrind
Why would you expect it to explode? – Oliver Charlesworth
@OliCharlesworth cause it has a lot of allocated memory not freed – Matteo
@Matteo: that's barely a couple MB at worst, no reason for it to "blow up" unless you're on a very constrained environment. – Mat
Real leaks, yes, as much as possible. But your expecting your program to blow up if it leaks is not reasonable. (That's also what can make leak tracking difficult - small leaks are usually harder to pinpoint that large ones.) – Mat
You should definitely fix all memory leaks as you become aware of them. As well as out-of-memory and performance problems, leaks can highlight other bugs you weren't aware of. However, more allocation-related crashes (explosions) occur - not when you loose track of an allocation, but conversely - when you keep hold of memory which has been deallocated. Reading to and writing from this memory causes undefined behavior. – John McFarlane

1 Answers

17
votes

I suggest visiting the Valgrind FAQ:

With Memcheck's memory leak detector, what's the difference between "definitely lost", "indirectly lost", "possibly lost", "still reachable", and "suppressed"?

The details are in the Memcheck section of the user manual.

In short:

  • "definitely lost" means your program is leaking memory -- fix those leaks!

  • "indirectly lost" means your program is leaking memory in a pointer-based structure. (E.g. if the root node of a binary tree is "definitely lost", all the children will be "indirectly lost".) If you fix the "definitely lost" leaks, the "indirectly lost" leaks should go away.

  • "possibly lost" means your program is leaking memory, unless you're doing unusual things with pointers that could cause them to point into the middle of an allocated block; see the user manual for some possible causes. Use --show-possibly-lost=no if you don't want to see these reports.

  • "still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.

  • "suppressed" means that a leak error has been suppressed. There are some suppressions in the default suppression files. You can ignore suppressed errors.