16

我最近一直在用 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，但是查看手册页，它没有说明如何清除它。知道如何正确摆脱这个吗？

4

3 回答 3

11

能够使用一些“hello world”代码重现此问题，该代码甚至不调用加载对象中的任何符号。 http://pastebin.com/d690bea57

我认为这是 libc 或 valgrind 中的错误。可在 Ubuntu 9.04 和 Scientific Linux 5.3 上重现（分别为 20 和 32 字节）。

编辑（由卡尔马里乌斯）：

这个简单的代码重现了这个问题：

#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 上重现这一点

上游bug已报告：https ://bugs.kde.org/show_bug.cgi?id=358980

于 2009-12-09T14:37:49.533 回答
4

这种抑制效果更好：

{
   Ignore dlopen bug.
   Memcheck:Leak
   ...
   fun:_dl_open
   ...
}

（请注意，“...”是抑制的一部分，应按字面意思输入。）

于 2010-09-06T07:56:11.830 回答
1

我自己在各种库中都看到过这个，无论是否使用 dlopen。我只是假设这是库中的一些魔术实现欺骗了 valgrind - 或者 - 这些库实际上确实存在内存泄漏，在这种情况下，我在我的应用程序中无能为力。

于 2009-10-16T22:35:11.313 回答