Still reachable in valgrind

Question

While searching about still reachable in valgrind, some people say its not a problem. we don't nedd to fix it. Some people say it needs to be fixed.I would be better if somebody could exaplain me explicitly what is the logic behind this still reachable. Is it mandatory to fix this?

[EDIT]

I have following valgrind output for my C program.Do i need to fix it?

      LEAK SUMMARY:
      ==27333==    definitely lost: 0 bytes in 0 blocks.
      ==27333==      possibly lost: 0 bytes in 0 blocks.
      ==27333==    still reachable: 96 bytes in 12 blocks.
      ==27333==         suppressed: 0 bytes in 0 blocks.

You haven't even said if this is a C or C++ program. – sharptooth Dec 10 '10 at 07:08 — sharptooth, Dec 10 '10 at 07:08
The above result is for my C program. – thetna Dec 10 '10 at 07:15 — thetna, Dec 10 '10 at 07:15

sharptooth · Accepted Answer · 2010-12-10T07:17:27.187

It depends. "Still reachable" means you haven't deallocated a block of memory before exiting, but had a pointer to it.

In a C++ program this means that some object could have not been deleted and therefore its destructor might not have been run and thus say some data might have not been saved onto disk for example and some other action might not have been taken and thus your program might produce unexpected behavior.

However there're no destructors in C programs, so your program just can't depend on that. Also deallocating memory takes some time, so by not freeing memory on exit you can save some time - your program will exit faster (this can be significant for programs with lots of data).

So IMO if your C program has "still reachable" blocks it's not a problem but this indicates that some code in the program doesn't free memory and so you can expect bugs when reusing that code.

Still reachable in valgrind

1 Answers1

Linked