Still reachable leak is reported with dlopen and pthread
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
valgrind (Debian) |
Fix Released
|
Unknown
|
|||
valgrind (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Valgrind reports still reachable leaks in dlopen()/dlclose() only when linked with -lpthread with the following code:
$ cat /tmp/valgrind-
#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-
$ 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-
$ 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-suppressi
...
==31414== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==31414== at 0x4C29DB4: calloc (in /usr/lib/
==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/
...
{
Still-reachable leak in dlopen/dlclose when linked to libpthread
Memcheck:Leak
fun:calloc
fun:_dlerror_run
fun:
fun:main
}
...
I don't know this should rather be fixed at libc...
description: | updated |
Changed in valgrind (Debian): | |
status: | Unknown → Fix Released |
Changed in valgrind (Debian): | |
status: | Fix Released → New |
Changed in valgrind (Debian): | |
status: | New → Fix Released |
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: default- dev is in universe for the time being. /bugs.kde. org/show_ bug.cgi? id=308717,
- 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-
- 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:/
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 ] spelling- in-manpage. patch xinclude- in-manpage. patch to fix a broken XInclude
* 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-
* Add 10_unbreak-
(Closes: #696694)
-- Alessandro Ghedini <email address hidden> Wed, 20 Feb 2013 11:21:07 +0100