0

I have noticed on a few programs that, while none of them have any memory leaks, flag a "still reachable" message when run via valgrind.

Does "still reachable" simply mean that there are pointers in the program that point to inaccessible or otherwise previously free'd memory? That seems to be the trend I have noticed but I'm not 100% sure. Is it good practice to fix these pointers or is it generally unnecessary?

Thank you,

GS

Improve this question
3
  • If it's 32 bytes still reachable, that would be a bug in combination with the recent compiler version and certain sanitizer settings. If it's more, there's probably a file not fclosed or some heap memory not freed.
    – Blauelf
    Sep 17 '19 at 17:18
  • The code in question that led me to believe was the free'ing of a linked list. I initially used three pointer variables to do this: first, ptr & tmp. I set ptr to very first pointer of the linked list (ptr = first). Then, inside a loop that terminates at the end of the linked list, I would remember ptr's current address (tmp = ptr), move to the next node with ptr (ptr = ptr->next), free the previous node (free(first)) and then set first to the previous position (tmp). This is when I noticed the still reachable leak. Naturally, I noticed it was inefficient and did the same with only 2 pointers.
    – Gabriel Saul
    Sep 17 '19 at 17:33
  • It was at that point did valgrind stop showing the still reachable leak, despite the fact that my code was essentially doing the same thing, just without the use of an extra variable. Does that make sense?
    – Gabriel Saul
    Sep 17 '19 at 17:37

You must log in to answer this question.

Browse other questions tagged .