By checking with valgrind, I see that 5 blocks of memory were not freed after terminating my program, but they are still reachable. Do I need to be bothered by it?
A
It depends.
It may well be a real leak, and it might not. But either way you should fix it.
If you allocate a buffer and keep it around all the way to the end of the program, technically it's a leak, but it doesn't matter - you only allocate one buffer, and it's basically permanent.
On the other hand perhaps you are allocating a buffer in a way that it's done just once in your test code, but later with the real code it might get allocated more than once - then you have a leak.
So it's best to fix them all.
No it is not a memory leak.
It means your program still has reference to memory that will freed later.
Valgrind FAQ differentiates between different messages as follows:
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, theindirectly lost
leaks should go away.possibly lost means your program is leaking memory, unless you're doing funny things with pointers. This is sometimes reasonable.
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.