Linux 上多线程 C++ 应用程序中的内存泄漏答案

【问题标题】：Memory leak in multi-threaded C++ application on LinuxLinux 上多线程 C++ 应用程序中的内存泄漏
【发布时间】：2012-06-14 13:58:43
【问题描述】：

我们有一个在 Linux 上运行的大型多线程 C++ 应用程序。我们看到应用程序占用的内存增长很快，并且认为存在一些泄漏。我们已经尝试了我们拥有的所有工具（valgrind、DynLeak、Purify），但没有找到任何东西。由于此应用程序可以在 Windows 上运行，我们还尝试了 Bounds Checker。也没有用。

我们需要一个可以提供帮助的新工具。我看过 Google Perfomrance Tools，Paul Nettle 的 MMGR，MemCheck Deluxe。他们都没有给我留下深刻印象。

有什么好工具可以完成这项任务吗？

【问题讨论】：

如果上述工具都找不到泄漏点，是什么让您相信存在泄漏点？您的应用程序可能正在使用所有内存。或者，您的应用程序可能会保留内存，即使它没有使用它。对于最后一种情况，不会有泄漏，只是内存使用或清理效率低下。
也许this 可以提供帮助。但是，如果使用其他工具未检测到泄漏，您如何确定存在内存泄漏？
泄漏可能在第三方库中，或者您可能只是在应用程序甚至操作系统中看到资源池和其他缓存的结果......大量内存使用并不是一个迹象内存泄漏必然。看看它是否在相同负载下随着时间不断增长。
1.我们认为存在泄漏，因为我们看到此应用程序占用的内存一直在增长。
2.这是一个成熟的应用程序，几年来使用相同的 3rd par 工具。我相信，如果泄漏是由这些工具引起的，我们本可以更早地看到它们。这不是一个案例。这是新事物。

标签： c++ linux memory-leak-detector

【解决方案1】：

在 C/C++ 中内存泄漏的定义非常具体：它是已分配的内存，然后指针被覆盖或以其他方式丢失。 Valgrind 通常可以开箱即用地检测到此类情况，但事情并不总是那么简单。

您的应用程序很可能仍在使用该内存。在这种情况下，您可能会遇到 Java 程序员认为的泄漏，例如在结构中输入数据并且很少（或从不）删除条目。
您可能错误地测量了内存的内存使用情况。在 Linux 上，内存使用测量并不像看起来那么简单。您是如何衡量您的内存使用情况的？
您应该考虑使用您正在使用的任何内存分析工具的应用程序挂钩（Valgrind 称它们为client requests），以避免仅在程序终止时发出报告的问题。使用这些钩子可能会帮助您确定泄漏的位置。
您应该尝试使用堆分析器（例如 Valgrind 的 massif）来查找分配内存过多的内存分配位置。
确保您没有在应用程序中使用自定义分配器或垃圾收集器。据我所知，没有user interference 的自定义分配器无法使用内存分析工具。
如果您的内存泄漏大到足以在可接受的应用程序运行时间内检测到，您可以尝试通过您的版本控制系统对旧修订进行二进制搜索，以确定导致问题的提交。至少Mercurial 和Git 提供对此任务的内置支持。

【讨论】：

【解决方案2】：

为了帮助您调试问题，也许在您的日志记录中，您还应该写入内存大小、对象数量（它们的类型）和一些其他对您有用的统计信息。至少在您更加熟悉您提到的工具之前。

【讨论】：

+1 用于应用内记录/调试代码。在我的一个应用程序中，我不得不检查 Windows 上的内存泄漏。当时我没有可用于该平台的工具，所以我围绕malloc() 和free() 编写了一个包装器，用于跟踪所有内存分配和释放。一个相当极端的解决方案，但它奏效了！
我同意你的观点，并已向我们的经理提出了这一建议。尽管如此，我还是想为这项工作找到一个经过验证的工具。你的方式非常复杂和令人厌烦。不过，如果没有任何帮助，我们会接受它。

【解决方案3】：

如果“没有帮助”是指它没有报告内存泄漏，则很可能您没有内存泄漏，只是使用越来越多的内存仍被指针引用并且可以删除。

【讨论】：

不幸的是，我们确实有一些东西。几个月前，在发生不明更改后，该应用程序开始表现得像这样。这就是我们寻找泄漏的原因。
@Michael：您是否尝试过通过您的版本控制系统进行二分搜索来识别导致泄漏的提交？
我希望它是可行的。我们有数十名开发人员在开发该应用程序。
@Michael：呃……为什么这会影响您执行二分搜索的能力？
修改次数太大。它们中的大多数是紧密耦合的。我们只是不能将更改分成独立的组来隔离问题。