代码之家 › 专栏 › 技术社区 › Anteru

Valgrind在DLopen报告内存泄漏?

dlopen valgrind memory-leaks

13

Anteru · 技术社区 · 15 年前

我最近一直在用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 但是看看手册页,它没有说明应该如何清除。你知道如何正确地解决这个问题吗?

3 回复 | 直到 8 年前

1

9

Calmarius 9 年前

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

我想这是libc或valgrind中的一个bug。可在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上重现。

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

2

StellarVortex 8 年前

这种抑制效果更好:

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

(请注意“…”是抑制的一部分,应逐字输入。)

3

1

James Morris 15 年前

我自己也在各种libs中看到过这个,使用dlopen还是不使用dlopen。我只是假设是libs中的一些神奇实现欺骗了valgrind——或者——这些libs确实有内存泄漏,在这种情况下,我在其中无能为力我的应用程序。