列表“冷”存储区 [英] list "cold" memory areas

问题描述

我试图在服务器软件中查找一个非常回避的错误，看起来像一个内存泄漏，但memcheck没有帮助。我的猜测是，已被实例化和从未删除的内存确实没有泄漏，所以有一个参考，但是现在是无用的程序，应该删除。
是否有一个工具可以对内存中的访问（而不是引用）进行计数，从而评估堆中对象的有效使用情况？

I'm trying to hunt down a very evasive bug in a server software that look like a memory leak, but memcheck didn't help at all. My guess is that the memory that has been instantiated and never removed is indeed not leaked, so there is a reference to it, but is now useless for the program and should be removed. Is there a tool that can count accesses, not references, in memory, and so give a evaluation of the effective usage of objects in heap?

推荐答案

我最终实现了自己的工具。
我的方法与我的意图略有不同：我写了一个 malloc钩子库。它钩住malloc，realloc和free，并维护一个活动malloc'd内存块的列表。每当您向应用程序发送SIGUSR1时，它会将其信息转储到文件中，并将其评估为 Mathematica 表达式。 Mathematica笔记本终于提供了一些非常有用的图表：通过调用堆栈的顶级得分实例化，以及完整的概述调用malloc 。使用这些工具，我只需要将鼠标悬停在最胖的，最远离第二个图形的中心绿点，并且，voilà，我有一个地址，实例化不泄露但无用的内存。

I ended up with implementing my own tool. My approach was slightly different from what I intended: I wrote a malloc hooking library. It hooks malloc, realloc and free, and maintains a list of living malloc'd memory blocks. Whenever you send a SIGUSR1 to your application, it dumps its info in a file, and evaluate it as a Mathematica expression. The Mathematica notebook finally provide some very useful graphs: top scored instantiations by call stack, and a complete overview of calls to malloc. With these tools, I just had to hover my mouse on the fattest and most distant from the center green dot of the second graph, and, voilà, I have the address that instantiates loads of not leaked but useless memory.

PS
在第二个图中可以看到的循环调用肯定是libc的backtrace（）中的一个错误。

P.S. The circular calls that you can see in the second graph are definitely a bug in libc's backtrace().

这篇关于列表“冷”存储区的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！