【问题标题】:list "cold" memory areas列出“冷”内存区域
【发布时间】:2012-01-28 02:25:24
【问题描述】:

我正试图在服务器软件中寻找一个看起来像内存泄漏的非常隐蔽的错误,但 memcheck 根本没有帮助。我的猜测是,已经实例化并且从未移除的内存确实没有泄漏,所以有引用它,但现在对程序没有用,应该移除。 有没有一种工具可以计算内存中的访问次数而不是引用次数,从而评估堆中对象的有效使用情况?

【问题讨论】:

  • Valgrind 应该将从未被释放的东西报告为“仍然可以访问”;见valgrind.org/docs/manual/faq.html#faq.deflost
  • @oli - 您可能希望发布您的评论作为答案,以便将其标记为已接受。无论如何,这对我来说似乎是正确的答案。
  • 我已经用这个程序运行了 memcheck,它没有显示任何内容。

标签: c++ memory-leaks


【解决方案1】:

我最终实现了自己的工具。 我的方法与我的意图略有不同:我写了一个malloc hooking library。它挂钩 malloc、realloc 和 free,并维护一个活的 malloc 内存块列表。每当您向应用程序发送 SIGUSR1 时,它会将其信息转储到文件中,并将其评估为 Mathematica 表达式。 Mathematica 笔记本终于提供了一些非常有用的图表:得分最高的实例化by call stack,以及calls to malloc 的完整概述。使用这些工具,我只需将鼠标悬停在距离第二张图的中心绿点最胖且距离最远的地方,瞧,我的地址可以实例化大量未泄漏但无用的内存。

附: 您可以在第二张图中看到的循环调用绝对是 libc 的 backtrace() 中的一个错误。

【讨论】:

  • 我很惊讶 valgrind 没有做你想做的事,没有发生内存泄漏 valgrind 没有为我处理。
  • 这个错误非常难以捉摸,还有一个原因:另一个人已经找到了一种在他的构建中可靠地触发它的方法,但该方法对我的不起作用(当然是相同的新鲜原始源)。所以 memcheck 显然没有为我找到任何东西,但是这个人告诉我他确实运行了 memcheck,但它什么也没返回,我没有理由认为他做错了什么。图表中显示的数据也来自他的构建。我怀疑这与位数有关,他构建了 32 位可执行文件以便能够在任何服务器上共享相同的构建,而我只构建了 64 位可执行文件。
【解决方案2】:

这个工具(Visual Leak Detector)可能会对您有所帮助。 它是免费的。

http://vld.codeplex.com/

【讨论】:

  • 它看起来像一个普通的泄漏检测器,正如我所说,我的问题是使用的额外内存在技术上没有泄漏,因为仍然有对它的引用。另外,我正在使用 gcc。
猜你喜欢
  • 2017-06-21
  • 2022-06-28
  • 2013-11-05
  • 2021-10-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-08-24
相关资源
最近更新 更多