dlopen 中 valgrind 报告内存泄漏?

发布于 2024-08-07 09:56:58 字数 1055 浏览 5 评论 0原文

我最近一直在使用 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 初始化的错误消息,但查看手册页,它没有说明如何清除它。知道如何正确摆脱这个吗?

I've been debugging some app lately with valgrind, and I'm getting very weird reports from 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>

This looks like the error message that is initialized for dlerror, but looking at the man page, it doesn't say anything about how this should be cleared. Any idea how to correctly get rid of this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

何处潇湘 2024-08-14 09:56:58

能够使用一些“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 上重现此问题

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

Was able to reproduce this issue with some 'hello world' code, which doesn't even call any symbols in the loaded object.
http://pastebin.com/d690bea57

I assume it's a bug in libc or valgrind.
Reproducible on Ubuntu 9.04 and Scientific Linux 5.3 (20 and 32 bytes respectively).

EDIT (by Calmarius):

This trivial code reproduces the problem:

#include <dlfcn.h>

int main()
{
    void* handle = 0;

    handle = dlopen("libm.so", RTLD_NOW);
    dlclose(handle);    

    return 0;
}

When compiled with this command:

gcc -Wl,--no-as-needed -g -o stuff  main.c -ldl -lpthread

Even the latest valgrind 3.11 can reproduce this on Ubuntu 14.04

Upstream bug has been reported: https://bugs.kde.org/show_bug.cgi?id=358980

所谓喜欢 2024-08-14 09:56:58

这种抑制效果更好:(

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

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

This suppression is better:

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

(Note that the "..." is part of the suppression and should be entered literally.)

|煩躁 2024-08-14 09:56:58

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

I've seen this myself in all sorts of libs, using dlopen or not. I just assumed it was some magic implementation within the libs which tricked valgrind - or - these libs actually do have memory leaks in which case there's nothing I can do within my app.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文