我最近用valgrind调试了一些应用程序,我从dlopen
得到了非常奇怪的报告。
==1987== 32 bytes in 1 blocks are still reachable in loss record 1 of 2
==1987== at 0x4C24477: calloc (vg_replace_malloc.c:418)
==1987== by 0x570F31F: _dlerror_run (dlerror.c:142)
==1987== by 0x570EEE0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
<my call to dlopen>
==1987==
==1987== 264 bytes in 1 blocks are still reachable in loss record 2 of 2
==1987== at 0x4C25153: malloc (vg_replace_malloc.c:195)
==1987== by 0x400CD44: _dl_map_object_deps (dl-deps.c:506)
==1987== by 0x4012DA2: dl_open_worker (dl-open.c:326)
==1987== by 0x400E385: _dl_catch_error (dl-error.c:178)
==1987== by 0x40126C6: _dl_open (dl-open.c:615)
==1987== by 0x570EF65: dlopen_doit (dlopen.c:67)
==1987== by 0x400E385: _dl_catch_error (dl-error.c:178)
==1987== by 0x570F2AB: _dlerror_run (dlerror.c:164)
==1987== by 0x570EEE0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
<my call to dlopen>
这看起来像是为dlerror
初始化的错误消息,但是查看手册页,它没有说明如何清除它。知道如何正确摆脱这个吗?
答案 0 :(得分:10)
能够使用一些“hello world”代码重现此问题,该代码甚至不会调用加载对象中的任何符号。 http://pastebin.com/d690bea57
我认为它是libc或valgrind中的一个错误。 可在Ubuntu 9.04和Scientific Linux 5.3上重现(分别为20和32字节)。
编辑(由Calmarius编写):这个简单的代码重现了这个问题:
#include <dlfcn.h>
int main()
{
void* handle = 0;
handle = dlopen("libm.so", RTLD_NOW);
dlclose(handle);
return 0;
}
使用此命令编译时:
gcc -Wl,--no-as-needed -g -o stuff main.c -ldl -lpthread
即使是最新的valgrind 3.11也可以在Ubuntu 14.04上重现这一点
答案 1 :(得分:2)
这种抑制效果更好:
{
Ignore dlopen bug.
Memcheck:Leak
...
fun:_dl_open
...
}
(请注意,“...”是抑制的一部分,应按字面输入。)
答案 2 :(得分:1)
我已经在各种lib中看到过这种情况,使用dlopen或不使用dlopen。我只是假设它是libs中的一些魔法实现,它欺骗了valgrind - 或者 - 这些lib实际上确实有内存泄漏,在这种情况下我无法在我的应用程序中做任何事情。