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

[Ryo Onodera]

Public bug reported:

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...

** Affects: valgrind (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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