内存泄漏调试

发布于 2024-08-06 04:44:40 字数 32 浏览 2 评论 0原文

如果没有跟踪工具,有哪些检测/调试内存泄漏的技术?

What are some techniques in detecting/debugging memory leak if you don't have trace tools?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

可爱暴击 2024-08-13 04:44:40

拦截所有分配和释放内存的函数(根据平台的不同,列表可能如下所示:malloc、calloc、realloc、strdup、getcwd、free),并且除了执行这些函数最初执行的操作之外,还将有关调用的信息保存在某处,可能在动态增长的全局数组中,受多线程程序的同步原语保护。

这些信息可能包括函数名称、请求的内存量、成功分配的块的地址、可让您找出调用者的堆栈跟踪等等。在 free() 中,从数组中删除相应的元素(如果没有,则将错误的指针传递给 free,这也是一个最好尽早检测到的错误)。当程序结束时,转储数组的剩余元素 - 它们将是泄漏的块。不要忘记分别在 main() 之前和之后分配和释放资源的全局对象。为了正确计算这些资源,您需要在最后一个全局对象被销毁后转储剩余资源,因此可能需要对编译器运行时进行一些小修改

Intercept all functions that allocate and deallocate memory (depending on the platform, the list may look like: malloc, calloc, realloc, strdup, getcwd, free), and in addition to performing what these functions originally do, save information about the calls somewhere, in a dynamically growing global array probably, protected by synchronization primitives for multithreaded programs.

This information may include function name, amount of memory requested, address of the successfully allocated block, stack trace that lets you figure out what the caller was, and so on. In free(), remove corresponding element from the array (if there are none, a wrong pointer is passed to free which is also a error that's good to be detected early). When the program ends, dump the remaining elements of the array - they will be the blocks that leaked. Don't forget about global objects that allocate and deallocate resources before and after main(), respectively. To properly count those resources, you will need to dump the remaining resources after the last global object gets destroyed, so a small hack of your compiler runtime may be necessary

汐鸠 2024-08-13 04:44:40
  1. 检查你的循环
  2. 看看你在哪里分配变量 - 你曾经取消分配它们吗?
  3. 尝试使用一小部分可疑代码来重现泄漏。
  4. 制作跟踪工具 - 您始终可以记录到文件中。
  1. Check out your loops
  2. Look at where you are allocating variables - do you ever de-allocate them?
  3. Try and reproduce the leak with a small subset of suspected code.
  4. MAKE trace tools - you can always log to a file.
上课铃就是安魂曲 2024-08-13 04:44:40

一种可能性是编译代码并在可以利用内置工具的系统上执行它(例如 libumem(Solaris 上),或 libc 功能

One possibility could be to compile the code and execute it on a system where you can take advantage of built in tools (e.g. libumem on Solaris, or the libc capability on Linux)

月寒剑心 2024-08-13 04:44:40

分而治之是最好的方法。如果您以系统的方式编写代码,那么调用代码的子集应该非常容易。最好的办法是一遍又一遍地执行每一段代码,看看你的内存使用量是否稳步上升,如果没有继续执行下一段代码。

此外,关于内存泄漏的维基百科文章在参考部分中有几个关于检测内存泄漏的很棒的链接适用于不同系统(window、macos、linux 等)

Divide and conquer is the best approach. If you have written you code in a systematic way, it should be pretty easy to call subsets of you code. Your best bet is to execute each section of code over and over and see if your memory usage steadily climbs, if not move on to the next section of code.

Also, the wikipedia article on memory leaks has several great links in the references section on detecting memory leaks for different systems (window, macos, linux, etc)

悟红尘 2024-08-13 04:44:40

关于SO的类似问题:

/stackoverflow.com/questions/600757/strategies-for-tracking-down-memory-leaks-when-youve-done-everything-wrong " 除了其他人提到的手动检查技术之外,您还应该考虑使用代码分析工具,例如 valgrind

他们网站的介绍:

Valgrind 是一款屡获殊荣的
建筑仪器仪表框架
动态分析工具。有
Valgrind 工具可以自动
检测许多内存管理和
线程错误,并分析您的
详细的计划。您还可以使用
Valgrind 构建新工具。

当前的 Valgrind 发行版
包括六种生产质量工具:
一个内存错误检测器,两个线程
错误检测器、缓存和
分支预测分析器
调用图生成缓存分析器,
和一个堆分析器。它还包括
两个实验工具:
堆/堆栈/全局数组溢出
探测器和 SimPoint 基本块
矢量发生器。它运行在
以下平台:X86/Linux,
AMD64/Linux、PPC32/Linux、PPC64/Linux、
和 X86/Darwin (Mac OS X)。

Similar questions on SO:

In addition to the manual inspection techniques mentioned by others, you should consider a code analysis tool such as valgrind.

Introduction from their site:

Valgrind is an award-winning
instrumentation framework for building
dynamic analysis tools. There are
Valgrind tools that can automatically
detect many memory management and
threading bugs, and profile your
programs in detail. You can also use
Valgrind to build new tools.

The Valgrind distribution currently
includes six production-quality tools:
a memory error detector, two thread
error detectors, a cache and
branch-prediction profiler, a
call-graph generating cache profiler,
and a heap profiler. It also includes
two experimental tools: a
heap/stack/global array overrun
detector, and a SimPoint basic block
vector generator. It runs on the
following platforms: X86/Linux,
AMD64/Linux, PPC32/Linux, PPC64/Linux,
and X86/Darwin (Mac OS X).

本王不退位尔等都是臣 2024-08-13 04:44:40

我用过memtrace
http://www.fpx.de/fp/Software/MemTrace/
http://sourceforge.net/projects/memtrace/

您可能需要调用统计函数来如果有任何泄漏,请打印输出。最好的办法是在执行模块或代码段之前和之后调用此统计函数。
* 警告 * Memtrace 足够好,允许内存覆盖/双重释放。它可以检测到这些异常并优雅地避免任何崩溃。

I have used memtrace
http://www.fpx.de/fp/Software/MemTrace/
http://sourceforge.net/projects/memtrace/

You may need to call the statistics function to printout if there are any leaks. Best thing is to call this statistics function before and after a module or piece of code gets executed.
* Warning * Memtrace is kind enough to allow memory overwrite/double free. It detects these anomalies and gracefully avoids any crash.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文