Still Reachable Leak detected by Valgrind

Question

All the functions mentioned in this block are library functions  How can I rectify this memory leak    It is listed under the  Still reachable  category   There are 4 more  which are very similar  but of varying sizes    630 bytes in 1 blocks are still reachable in loss record 5 of 5     at 0x4004F1B  calloc  vg replace malloc c 418      by 0x931CD2   dl new object  dl-object c 52      by 0x92DD36   dl map object from fd  dl-load c 972      by 0x92EFB6   dl map object  dl-load c 2251      by 0x939F1B  dl open worker  dl-open c 255      by 0x935965   dl catch error  dl-error c 178      by 0x9399C5   dl open  dl-open c 584      by 0xA64E31  do dlopen  dl-libc c 86      by 0x935965   dl catch error  dl-error c 178      by 0xA64FF4    libc dlopen mode  dl-libc c 47      by 0xAE6086  pthread cancel init  unwind-forcedunwind c 53      by 0xAE61FC   Unwind ForcedUnwind  unwind-forcedunwind c 126    Catch  Once I ran my program  it gave no memory leaks  but it had one additional line in the Valgrind output  which wasn t present before      Discarding syms at 0x5296fa0-0x52af438   in  lib libgcc s-4 4 4-20100630 so 1   due to munmap     If the leak can t be rectified  can someone atleast explain why the munmap   line causes Valgrind to report 0  still reachable  leaks   Edit   Here s a minimal test sample    include  lt stdio h gt   include  lt stdlib h gt   include  lt pthread h gt   void  runner void  param           some operations            pthread exit NULL      int n   int main void         int i      pthread t  threadIdArray       n 10     for example         threadIdArray   malloc  n n-1  sizeof pthread t           for i 0 i lt  n n-1  i              if  pthread create  amp threadIdArray i  NULL runner NULL     0                 printf  Couldn t create thread  d n  i               exit 1                         for i 0 i lt  n n-1  i              pthread join threadIdArray i  NULL              free threadIdArray        return 0       Run with   valgrind -v --leak-check full --show-reachable yes   a out

User · Answer

You don t appear to understand what still reachable means   Anything still reachable is not a leak  You don t need to do anything about it

User · Answer

Here is a proper explanation of  still reachable     Still reachable  are leaks assigned to global and static-local variables  Because valgrind tracks global and static variables it can exclude memory allocations that are assigned  once-and-forget   A global variable assigned an allocation once and never reassigned that allocation is typically not a  leak  in the sense that it does not grow indefinitely   It is still a leak in the strict sense  but can usually be ignored unless you are pedantic   Local variables that are assigned allocations and not free d are almost always leaks   Here is an example  int foo void        static char  working buf   NULL      char  temp buf      if   working buf             working buf    char    malloc 16   1024             temp buf    char    malloc 5   1024                                    Valgrind will report working buf as  still reachable - 16k  and temp buf as  definitely lost - 5k

User · Answer

For future readers   Still Reachable  might mean you forgot to close something like a file  While it doesn t seem that way in the original question  you should always make sure you ve done that

User · Answer

Since there is some routine from the the pthread family on the bottom  but I don t know that particular one   my guess would be that you have launched some thread as joinable that has terminated execution   The exit state information of that thread is kept available until you call pthread join  Thus  the memory is kept in a loss record at program termination  but it is still reachable since you could use pthread join to access it   If this analysis is correct  either launch these threads detached  or join them before terminating your program   Edit  I ran your sample program  after some obvious corrections  and I don t have errors but the following    18933   ERROR SUMMARY  0 errors from 0 contexts  suppressed  4 from 4  --18933--  --18933-- used suppression       2 dl-hack3-cond-1 --18933-- used suppression       2 glibc-2 5 x-on-SUSE-10 2- PPC -2a   Since the dl- thing resembles much of what you see I guess that you see a known problem that has a solution in terms of a suppression file for valgrind  Perhaps your system is not up to date  or your distribution doesn t maintain these things   Mine is ubuntu 10 4  64bit

User · Answer

There is more than one way to define  memory leak   In particular  there are two primary definitions of  memory leak  that are in common usage among programmers   The first commonly used definition of  memory leak  is   Memory was allocated and was not subsequently freed before the program terminated   However  many programmers  rightly  argue that certain types of memory leaks that fit this definition don t actually pose any sort of problem  and therefore should not be considered true  memory leaks    An arguably stricter  and more useful  definition of  memory leak  is   Memory was allocated and cannot be subsequently freed because the program no longer has any pointers to the allocated memory block   In other words  you cannot free memory that you no longer have any pointers to  Such memory is therefore a  memory leak   Valgrind uses this stricter definition of the term  memory leak   This is the type of leak which can potentially cause significant heap depletion  especially for long lived processes   The  still reachable  category within Valgrind s leak report refers to allocations that fit only the first definition of  memory leak   These blocks were not freed  but they could have been freed  if the programmer had wanted to  because the program still was keeping track of pointers to those memory blocks   In general  there is no need to worry about  still reachable  blocks  They don t pose the sort of problem that true memory leaks can cause  For instance  there is normally no potential for heap exhaustion from  still reachable  blocks  This is because these blocks are usually one-time allocations  references to which are kept throughout the duration of the process s lifetime  While you could go through and ensure that your program frees all allocated memory  there is usually no practical benefit from doing so since the operating system will reclaim all of the process s memory after the process terminates  anyway  Contrast this with true memory leaks which  if left unfixed  could cause a process to run out of memory if left running long enough  or will simply cause a process to consume far more memory than is necessary   Probably the only time it is useful to ensure that all allocations have matching  frees  is if your leak detection tools cannot tell which blocks are  still reachable   but Valgrind can do this  or if your operating system doesn t reclaim all of a terminating process s memory  all platforms which Valgrind has been ported to do this

[c] Still Reachable Leak detected by Valgrind

Examples related to c

Examples related to pthreads

Examples related to valgrind