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

[Bug Watch Updater]

** Changed in: valgrind (Debian)
       Status: New => Fix Released

-- 
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:
  Fix Released
Status in “valgrind” package in Debian:
  Fix Released

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