Still reachable leak is reported with dlopen and pthread

[Ryo Onodera]

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

[Colin Watson (cjwatson)]

Fixed independently in Debian, and making its way into saucy now via a merge. Thanks.

valgrind (1:3.8.1-3ubuntu1) saucy; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Allow specification of an extra directory in which to look for
      debuginfo objects.
    - Remove valgrind-mpi package from Ubuntu and any references to it, as
      mpi-default-dev is in universe for the time being.
    - Lower over-inflated valgrind-dbg Recommends to Suggests instead.
    - Don't strip vgpreload* on ARM; this results in unusable stack traces
      without valgrind-dbg.
    - Apply patch from https://bugs.kde.org/show_bug.cgi?id=308717,
      implementing fixed-point VCVT.F64.[SU]32 on ARM. This instruction
      shows up quite frequently in desktop components.
  * Drop remaining ppc64 patches; we no longer care about this in Ubuntu,
    and valgrind seems to build fine on Debian ppc64.
  * Renumber Ubuntu patches to make future merges easier.

 -- Colin Watson <email address hidden> Thu, 30 May 2013 11:09:43 +0100

valgrind (1:3.8.1-3) unstable; urgency=low

  * Add 11_glibc-2.17.patch to fix FTBFS with glibc 2.17 (Closes: #707438)

 -- Alessandro Ghedini <email address hidden> Fri, 10 May 2013 18:10:39 +0200

valgrind (1:3.8.1-2) unstable; urgency=low

  [ Alessandro Ghedini ]
  * Bump Standards-Version to 3.9.4 (no changes needed)
  * Quote LD_LIBRARY_PATH in the wrapper script to avoid errors with spaced
    paths (LP: #880685)
  * Enable support for mipsel too (Closes: #696850)
  * Add suppression for dlopen() leak when linking with -lpthread
    (Closes: #700899)

  [ Samuel Bronson ]
  * Allow building more than once from the same tree
    - Build and ship FAQ.txt from sources, since the bundled copy is deleted
      on "make clean"
  * Drop docs/valgrind.1 changes from 08_fix-spelling-in-manpage.patch
  * Add 10_unbreak-xinclude-in-manpage.patch to fix a broken XInclude
    (Closes: #696694)

 -- Alessandro Ghedini <email address hidden> Wed, 20 Feb 2013 11:21:07 +0100

[Lewis ANESA (djtecking)]

Same issue seen with valgrind while developing on Vulkan core.
Bug related on github here :
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/1298