dlopen 中 valgrind 报告内存泄漏?
我最近一直在使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
能够使用一些“hello world”代码重现此问题,该代码甚至不调用加载对象中的任何符号。
http://pastebin.com/d690bea57
我认为这是 libc 或 valgrind 中的错误。
可在 Ubuntu 9.04 和 Scientific Linux 5.3 上重现(分别为 20 和 32 字节)。
编辑(由 Calmarius):
这个简单的代码重现了问题:
使用此命令编译时:
即使是最新的 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:
When compiled with this command:
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
这种抑制效果更好:(
请注意,“...”是抑制的一部分,应按字面意思输入。)
This suppression is better:
(Note that the "..." is part of the suppression and should be entered literally.)
我自己在各种库中都看到过这种情况,无论是否使用 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.