假设我有一个C程序(在Linux下运行),它操纵许多数据结构,一些复杂,其中一些可以增长和缩小,但通常不会随着时间的推移而增长。观察到该程序随着时间的推移逐渐增加RSS(比可以通过内存碎片解释的更多)。我想找到泄漏的东西。在valgrind
下运行是明显的建议,但valgrind
(--leak-check=full
和--show-reachables=yes
)显示没有泄漏。我相信这是因为数据结构本身在退出时正确释放,但其中一个在程序的生命周期中正在增长。例如,可能有一个链接列表随着时间的推移呈线性增长,有人忘记删除列表中的资源,但退出清理正确地在退出时释放列表中的所有项目。当然,如果它们被释放,那么它们是否实际上是“泄漏”存在一个哲学问题(因此问题中的引号)。
是否有任何有用的工具可用于检测?我喜欢的是能够在valgrind
下运行并让它生成当前分配的报告,就像它在退出时一样,但要在信号上发生这种情况并允许程序继续。然后,我可以查找堆栈跟踪签名对它们的分配越来越多。
我可以使用gdb
从generate-core-file
可靠地获取一个漂亮的大型'核心'文件;有没有办法分析离线,如果我用一个方便的malloc()
编译的malloc()
调试库编译?
我可以完全访问源代码,并且可以修改它,但我真的不想手动检测每个数据结构,而且我对这个问题的一般解决方案感兴趣(比如valgrind
提供)而不是如何解决这个特定的问题。
我在这里寻找类似的问题,但它们似乎都是:
如果我在Solaris下运行,我猜测答案是“使用这个方便的dtrace
脚本”。
答案 0 :(得分:5)
Valgrind包含一个gdbserver。这基本上意味着您可以使用gdb连接到它,例如发出泄漏转储,或在运行时显示所有可访问的内存。当然,你必须判断是否存在内存泄漏问题。或不是,因为valgrind无法知道应用程序逻辑中是否存在无法释放内存的错误,但仍然保留对它的引用。
使用--vgdb = yes标志运行valgrind,然后运行命令:
valgrind --vgdb=yes --leak-check=full --show-reachable=yes ./yourprogram
gdb ./yourprogram
(gdb) target remote | vgdb
(gdb) monitor leak_check full reachable any
您也可以在程序中执行此操作programatically
#include <valgrind/memcheck.h>
并在代码中的适当位置执行:
VALGRIND_DO_LEAK_CHECK;
(只要valgrind与--show-reachable = yes
一起运行,iirc也会显示可达的内存)答案 1 :(得分:1)
有Valgrind Massif工具显示应用程序的一般内存使用情况,而不仅仅是泄漏的内存。它通过调用函数及其回溯来分解malloc()
和free()
,因此您可以看到哪些函数在不释放内存的情况下继续分配内存。这可以成为查找您提到的类型泄漏的绝佳工具。
不幸的是,围绕Massif的工具有点奇怪...... Valgrind提供的ms_print
工具仅对最基本的任务有用;对于实际工作,你可能想要一些显示图形的东西。网上散布着几种工具 - 参见例如。 Valgrind Massif tool output graphical interface?。