linux上的轻量级内存泄漏调试
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/18455698/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Lightweight memory leak debugging on linux
提问by glagolig
I looked for existing answers first and saw that Valgrindis everyone's favorite tool for memory leak debugging on linux. Unfortunately Valgrinddoes not seem to work for my purposes. I will try to explain why.
我首先寻找现有的答案，发现Valgrind是每个人最喜欢的 Linux 内存泄漏调试工具。不幸的是，Valgrind似乎不适合我的目的。我将尝试解释原因。
Constraints:
约束：
- The leak reproduces only in customer's environment. Due to certain legal restrictions we have to work with existing binary. No rebuilds.
- In regular environment our application consumes ~10% CPU. Say, we can tolerate up to 10x CPU usage increase. Valgrindwith default memchecksettings does much worse making our application unresponsive for long periods of time.
- 泄漏仅在客户环境中重现。由于某些法律限制，我们必须使用现有的二进制文件。没有重建。
- 在常规环境中，我们的应用程序消耗约 10% 的 CPU。比如说，我们可以容忍高达 10 倍的 CPU 使用率增加。具有默认memcheck设置的Valgrind做得更糟，使我们的应用程序长时间无响应。
What I need is an equivalent of Microsoft's UMDH: turn on stack tracing for each heap allocation, then at certain point of time dump all allocations grouped by stacks and ordered by allocation count in descending order. Our app ships on both Windows and Linux platforms, so I know that performance on Windows under UMDHis still tolerable.
我需要的是 Microsoft 的UMDH等价物：为每个堆分配打开堆栈跟踪，然后在某个时间点转储按堆栈分组并按分配计数降序排列的所有分配。我们的应用程序在 Windows 和 Linux 平台上发布，所以我知道在UMDH下的 Windows 上的性能仍然可以接受。
Here are the tools/methods I considered
以下是我考虑过的工具/方法
- Valgrind's -memcheckand –massiftools They do much more than needed (like scanning whole process memory for every allocation
pointer), they are too slow, and they still don't do exactly what I
need (dump callstacks sorted by counts), so I will have to write some scripts parsing the output - dmalloclibrary (dmalloc.com) requires new binary
- LeakTracer (http://www.andreasen.org/LeakTracer/) Works only with C++ new/delete(I need malloc/freeas well), does not have group-by-stack and sort functionality
- Implementing the tool myself as .so library using LD_PRELOAD mechanism (Overriding 'malloc' using the LD_PRELOAD mechanism) That will take at least a week given my coding-for-Linux skills and it feels like inventing a bicycle.
- Valgrind的-memcheck和-massif工具它们做的比需要的多得多（比如扫描整个进程内存以获取每个分配指针），它们太慢了，而且它们仍然不能完全满足我的
需要（按计数排序转储调用堆栈） ，所以我将不得不编写一些脚本来解析输出 - dmalloc库 (dmalloc.com) 需要新的二进制文件
- LeakTracer ( http://www.andreasen.org/LeakTracer/) 仅适用于 C++ new/delete（我也需要malloc/free），没有按堆栈分组和排序功能
- 使用 LD_PRELOAD 机制将工具自己实现为 .so 库（使用 LD_PRELOAD 机制覆盖“malloc”）考虑到我的 Linux 编码技能，这至少需要一周时间，感觉就像发明了一辆自行车。
Did I miss anything? Are there any lightweight Valgrindoptions or existing LD_PRELOAD tool?
我错过了什么吗？是否有任何轻量级Valgrind选项或现有的 LD_PRELOAD 工具？
采纳答案by glagolig
Surprisingly, I was unable to find anything like Microsoft's UMDH in open-source domain or available for immediate download. (I also looked at Google Heap Leak Checkerbut it is more like Valgrind rather than to UMDH). So I ended up writing the tool myself using malloc instrumentationproject as a reference point:
令人惊讶的是，我无法在开源域中找到类似 Microsoft 的 UMDH 或可立即下载的内容。（我还查看了Google Heap Leak Checker，但它更像是 Valgrind 而不是 UMDH）。所以我最终使用malloc 检测项目作为参考点自己编写了该工具：
https://github.com/glagolig/heapwatch
https://github.com/glagolig/heapwatch
The tool has number of limitations, but it worked just fine for my purposes.
该工具有许多限制，但它对我的目的来说效果很好。
回答by DanielKO
GNU libc has built-in malloc debugging:
GNU libc 有内置的 malloc 调试：
http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html
http://www.gnu.org/software/libc/manual/html_node/Allocation-Debugging.html
Use LD_PRELOAD to call mtrace()from your own .so:
使用 LD_PRELOADmtrace()从您自己的 .so调用：
#include <mcheck.h>
static void prepare(void) __attribute__((constructor));
static void prepare(void)
{
mtrace();
}
Compile it with:
编译它：
gcc -shared -fPIC dbg.c -o dbg.so
Run it with:
运行它：
export MALLOC_TRACE=out.txt
LD_PRELOAD=./dbg.so ./my-leaky-program
Later inspect the output file:
稍后检查输出文件：
mtrace ./my-leaky-program out.txt
And you will get something like:
你会得到类似的东西：
Memory not freed:
-----------------
Address Size Caller
0x0000000001bda460 0x96 at /tmp/test/src/test.c:7
Of course, feel free to write your own malloc hooks that dump the entire stack (calling backtrace()if you think that's going to help).
当然，您可以随意编写自己的 malloc 钩子来转储整个堆栈（如果您认为这会有所帮助，请调用backtrace()）。
Lines numbers and/or function names will be obtainable if you kept debug info for the binary somewhere (e.g. the binary has some debug info built in, or you did objcopy --only-keep-debug my-leaky-program my-leaky-program.debug).
如果您将二进制文件的调试信息保存在某处（例如，二进制文件内置了一些调试信息，或者您这样做了objcopy --only-keep-debug my-leaky-program my-leaky-program.debug），则可以获得行号和/或函数名称。
Also, you could try Boehm's GC, it works as a leak detector too:
此外，您可以尝试 Boehm 的 GC，它也可以用作泄漏检测器：
回答by SebGR
MemoryScapewould meet your needs. This is the dynamic memory debugging tool that comes with the TotalViewdebugger.
MemoryScape将满足您的需求。这是TotalView调试器附带的动态内存调试工具。
回答by Chris Gottbrath
@glagolig,
@glagolig，
Yes, MemoryScape can group allocations by stack location.
是的，MemoryScape 可以按堆栈位置对分配进行分组。
Were you able to get the evaluation version? Assuming you used an email address that doesn't look like a bot you should have heard back from us pretty quickly. If not, or if you are having technical trouble with it give me a shout or reach out to our tech support team.
你能拿到评估版吗？假设您使用了一个看起来不像机器人的电子邮件地址，您应该很快就会收到我们的回复。如果没有，或者如果您遇到技术问题，请告诉我或联系我们的技术支持团队。
Chris Gottbrath
克里斯·戈特布拉斯
Principal Product Manager for TotalView at Rogue Wave Software
Rogue Wave Software 的 TotalView 首席产品经理
email: Firstname . Lastname (at) roguewave . com
电子邮件：名字。姓 (at) roguewave 。电脑
回答by milianw
I would like to advertise my just announced heaptrack utility, which should be just what you where looking for back then. You can find more information here: http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
我想宣传我刚刚宣布的 heaptrack 实用程序，这应该正是您当时正在寻找的。您可以在此处找到更多信息：http: //milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
Compared to your heapwatch tool, the performance should be far better, as I use libunwind and later libbacktrace to delay the annotation of the backtrace with DWARF debug information.
与你的 heapwatch 工具相比，性能应该好得多，因为我使用 libunwind 和后来的 libbacktrace 来延迟带有 DWARF 调试信息的回溯的注释。
I'd love to get more feedback on it, so try it out!
我很想得到更多关于它的反馈，所以试试吧！
回答by Bingzheng Wu
memleaxshould work for you.
memleax应该适合你。
It debugs memory leak of a running process by attaching it, without recompiling program or restarting target process. It's very convenient and suitable for production environment.
它通过附加来调试正在运行的进程的内存泄漏，而无需重新编译程序或重新启动目标进程。非常方便，适合生产环境。
It TRAPs only for malloc/free() calls, so it should bring less performace impact than Vagrild.
它仅针对 malloc/free() 调用进行陷阱处理，因此它对性能的影响应该比 Vagrild 小。
It works on GNU/Linux-x86_64 and FreeBSD-amd64.
它适用于 GNU/Linux-x86_64 和 FreeBSD-amd64。
NOTE: I'm the author, any suggestion is welcomed
注意：我是作者，欢迎任何建议
回答by Tim Boddy
There is a free, open source tool called chap that will do most of what you want. It specifically will not give you stack traces, but it is an extremely light weight tool because it doesn't require any instrumentation at all. All you need is to be able to grab a live core of the process in question, at a point at which you believe the process has already exhibited the bug (so you believe that it has leaked or is too large or whatever).
有一个名为 chap 的免费开源工具可以完成您想要的大部分工作。它特别不会给你堆栈跟踪，但它是一个非常轻量级的工具，因为它根本不需要任何仪器。您所需要的只是能够获取相关流程的实时核心，此时您认为该流程已经表现出错误（因此您认为它已泄漏或太大或其他）。
For details, see https://github.com/vmware/chap
回答by Gerald Chu
You might also consider using Google's gperftools, which has a heap profiler that can be loaded via LD_PRELOAD. You can also link in its tcmalloc and leak checker into your binary, and enable them only when needed.
您也可以考虑使用 Google 的 gperftools，它有一个可以通过 LD_PRELOAD 加载的堆分析器。您还可以将其 tcmalloc 和泄漏检查器链接到您的二进制文件中，并仅在需要时启用它们。
For details, see https://github.com/gperftools/gperftools
