valgrind-在共享库中查找内存泄漏 [英] valgrind - Find memory leak in a shared library

问题描述

我需要知道在共享库中找出内存泄漏的方法，该库将被加载到发行二进制文件中.我的意思是我使用-g选项构建的共享库，但加载该共享库的二进制文件不是使用-g选项构建的.

I need to know ways to find out the memory leaks in a shared library which will be loaded to a release binary. I mean shared library I built with -g option but the binary that loads the shared library is not built with -g option.

我收到如下的泄漏报告.

I get the leak report as follows.

==739==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==739==    by 0x84781B1: ???
==739==    by 0x87507F5: ???
==739==    by 0x874CF47: ???
==739==    by 0x874E657: ???
==739==    by 0x874F7C2: ???
==739==    by 0x8779C0C: ???

请让我知道如何从共享库获取泄漏的堆栈跟踪?

Please let me know how to get the stack trace of the leak from the shared library?

推荐答案

假设泄漏确实来自您的共享库，那么我认为问题不在于主要可执行文件缺少调试功能.

Assuming that the leak really is coming from your shared library then I don't think the problem is the lack of debugging in the main executable.

您的问题很可能是可执行文件通过在完成之前调用dlclose来卸载共享库.这意味着当valgrind检查泄漏时，该库的所有符号信息都消失了，因为不再加载该库.

More likely your problem is that the executable is unloading the shared library by calling dlclose before it finishes. That means that when valgrind comes to check for leaks all the symbol information for the library is gone as the library is no longer loaded.

如果您可以重建可执行文件，则最简单的解决方案可能是暂时停止调用dlclose使其可执行程序，以便库保持加载状态直至结束.

If you can rebuild the executable then the easiest solution may be to temporarily stop it calling dlclose so that the library stays loaded until the end.

如果您无法执行此操作，请尝试使用LD_PRELOAD保持库加载，如下所示:

If you can't do that, then try using LD_PRELOAD to keep the library loaded, like this:

LD_PRELOAD="/path/to/library.so" valgrind my-executable

这将有望诱使动态链接器即使在关闭库后仍保持加载状态.

which will hopefully trick the dynamic linker into keeping the library loaded even after it has been closed.

这篇关于valgrind-在共享库中查找内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！