[Bug 1160352] Re: Still reachable leak is reported with dlopen and pthread

[Ryo Onodera]

** Description changed:

  Valgrind reports still reachable leaks in dlopen()/dlclose() only when
  linked with -lpthread with the following code:
  
- $ cat /tmp/valgrind-dlopen-pthread-leak.c 
+ $ cat /tmp/valgrind-dlopen-pthread-leak.c
  #include <stdio.h>
  #include <dlfcn.h>
  
  int main() {
-   char *error = 0;
+   char *error = 0;
  
-   void *handle = dlopen(NULL, RTLD_NOW | RTLD_GLOBAL);
+   void *handle = dlopen(NULL, RTLD_NOW | RTLD_GLOBAL);
  
-   if((error = dlerror())) {
-     printf("dlopen failed: %s\n", error);
-     return 1;
-   }
-   printf("%p\n", handle);
+   if((error = dlerror())) {
+     printf("dlopen failed: %s\n", error);
+     return 1;
+   }
+   printf("%p\n", handle);
  
-   dlclose(handle);
+   dlclose(handle);
  
-   if((error = dlerror())) {
-     printf("dlclose failed: %s\n", error);
-     return 1;
-   }
+   if((error = dlerror())) {
+     printf("dlclose failed: %s\n", error);
+     return 1;
+   }
  
-   return 0;
+   return 0;
  }
  
  This code correctly dlopen()s and dlclose()s, so there should be no leak
  whatsoever. And this can be confirmed from the result of valgrind
  without -lpthread:
  
  $ gcc /tmp/valgrind-dlopen-pthread-leak.c -ldl
  $ valgrind ./a.out
  ...
  ==31371== All heap blocks were freed -- no leaks are possible
  ...
  
  But this doesn't hold once I compile the sample code with -lpthread:
  
  $ gcc /tmp/valgrind-dlopen-pthread-leak.c -ldl -lpthread
  $ valgrind ./a.out
  ...
  ==31363== LEAK SUMMARY:
  ==31363==    definitely lost: 0 bytes in 0 blocks
  ==31363==    indirectly lost: 0 bytes in 0 blocks
  ==31363==      possibly lost: 0 bytes in 0 blocks
  ==31363==    still reachable: 32 bytes in 1 blocks
  ==31363==         suppressed: 0 bytes in 0 blocks
  ...
  
  I've created a suppresion for this:
  
- $ valgrind --gen-suppressions=yes --leak-check=full --show-reachable=yes ./a.out
+ $ valgrind --gen-suppressions=all --leak-check=full --show-reachable=yes ./a.out
  ...
  ==31414== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
  ==31414==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==31414==    by 0x4E3359F: _dlerror_run (dlerror.c:142)
  ==31414==    by 0x4E32FC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
  ==31414==    by 0x400662: main (in /home/ryoqun/dev/rubinius/rubinius-master/a.out)
  ...
  {
-    Still-reachable leak in dlopen/dlclose when linked to libpthread
-    Memcheck:Leak
-    fun:calloc
-    fun:_dlerror_run
-    fun:dlopen@@GLIBC_2.2.5
-    fun:main
+    Still-reachable leak in dlopen/dlclose when linked to libpthread
+    Memcheck:Leak
+    fun:calloc
+    fun:_dlerror_run
+    fun:dlopen@@GLIBC_2.2.5
+    fun:main
  }
  ...
  
  I don't know this should rather be fixed at libc...

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to valgrind in Ubuntu.
https://bugs.launchpad.net/bugs/1160352

Title:
  Still reachable leak is reported with dlopen and pthread

Status in “valgrind” package in Ubuntu:
  New

Bug description:
  Valgrind reports still reachable leaks in dlopen()/dlclose() only when
  linked with -lpthread with the following code:

  $ cat /tmp/valgrind-dlopen-pthread-leak.c
  #include <stdio.h>
  #include <dlfcn.h>

  int main() {
    char *error = 0;

    void *handle = dlopen(NULL, RTLD_NOW | RTLD_GLOBAL);

    if((error = dlerror())) {
      printf("dlopen failed: %s\n", error);
      return 1;
    }
    printf("%p\n", handle);

    dlclose(handle);

    if((error = dlerror())) {
      printf("dlclose failed: %s\n", error);
      return 1;
    }

    return 0;
  }

  This code correctly dlopen()s and dlclose()s, so there should be no
  leak whatsoever. And this can be confirmed from the result of valgrind
  without -lpthread:

  $ gcc /tmp/valgrind-dlopen-pthread-leak.c -ldl
  $ valgrind ./a.out
  ...
  ==31371== All heap blocks were freed -- no leaks are possible
  ...

  But this doesn't hold once I compile the sample code with -lpthread:

  $ gcc /tmp/valgrind-dlopen-pthread-leak.c -ldl -lpthread
  $ valgrind ./a.out
  ...
  ==31363== LEAK SUMMARY:
  ==31363==    definitely lost: 0 bytes in 0 blocks
  ==31363==    indirectly lost: 0 bytes in 0 blocks
  ==31363==      possibly lost: 0 bytes in 0 blocks
  ==31363==    still reachable: 32 bytes in 1 blocks
  ==31363==         suppressed: 0 bytes in 0 blocks
  ...

  I've created a suppresion for this:

  $ valgrind --gen-suppressions=all --leak-check=full --show-reachable=yes ./a.out
  ...
  ==31414== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
  ==31414==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==31414==    by 0x4E3359F: _dlerror_run (dlerror.c:142)
  ==31414==    by 0x4E32FC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
  ==31414==    by 0x400662: main (in /home/ryoqun/dev/rubinius/rubinius-master/a.out)
  ...
  {
     Still-reachable leak in dlopen/dlclose when linked to libpthread
     Memcheck:Leak
     fun:calloc
     fun:_dlerror_run
     fun:dlopen@@GLIBC_2.2.5
     fun:main
  }
  ...

  I don't know this should rather be fixed at libc...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1160352/+subscriptions