| 2013-03-26 13:09:30 |
Ryo Onodera |
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=yes --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... |
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... |
|
