有没有一种方法可以仅查看生成的核心文件来定位进程的哪一部分使用了最多的内存？

Question

我有一个进程（每次都由看门狗启动，由于某种原因停止），通常使用大约 200MB 内存。一旦我看到它正在耗尽内存 - 内存使用量约为 1.5-2GB，这绝对意味着某处存在“内存泄漏”（引号中的“内存泄漏”，因为这不是真正的内存泄漏 - 就像分配的内存，从未释放< strong>并且无法访问 - 请注意，仅使用智能指针所以，我想到了一些巨大的容器（我没有找到）或类似的东西）

后来的过程。由于内存过高而崩溃使用情况并生成核心转储 - 大约 2GB。但问题是，我无法重现该问题，因此 valgrind 在这里无济于事（我猜）。这种情况很少发生，我无法“抓住”它。

所以，我的问题是 - 有没有办法使用 exe 和核心文件来定位进程的哪一部分使用了大部分内存？

我用gdb，没有什么异常。但核心很大，所以一定有东西。有没有一种聪明的方法来理解发生了什么，或者只是猜测可能有帮助（但是对于这么大的exe..，12个线程，大约50-100（可能更多）类，等等）

这是一个C++ 应用程序，在 RHEL5U3 上运行。

Answer 1

以十六进制格式（如 bytes/words/dwords/qwords）打开此核心转储。从文件的中间开始尝试注意任何重复的模式。如果发现任何东西，请尝试确定起始地址和某些可能的数据结构的长度。使用该结构的长度和内容，尝试猜测它可能是什么。使用该地址，尝试找到指向该结构的一些指针。重复直到到达堆栈或某个全局变量。如果是堆栈变量，您将很容易知道该链在哪个函数中开始。对于全局变量，您至少知道它的类型。

如果您在核心转储中找不到任何模式，则泄漏结构很可能非常大。只需将您在文件中看到的内容与程序中所有大型结构的可能内容进行比较即可。

更新

如果您的核心转储具有有效的调用堆栈，您可以从检查其函数开始。寻找任何不寻常的东西。检查调用堆栈顶部附近的内存分配是否不会请求太多。检查调用堆栈函数中是否存在可能的无限循环。

“仅使用智能指针”这句话让我感到害怕。如果这些智能指针的重要部分是共享指针（shared_ptr，intrusive_ptr，...），则值得搜索共享指针循环，而不是搜索巨大的容器。

更新 2

尝试确定堆在核心文件中的结束位置（brk 值）。在 gdb 下运行 coredumped 进程并使用 pmap 命令（从其他终端）。 gdb 也应该知道这个值，但我不知道如何询问它...如果大部分进程的内存都在 brk 之上，您可以通过大内存分配来限制您的搜索（最有可能的是， std::向量）。

为了提高在现有核心转储的堆区域中发现泄漏的机会，可以使用一些编码（我自己没有这样做，只是一个理论）：

• 读取核心转储文件，将每个值解释为指针（忽略代码段，未对齐的值） ，以及指向非堆区域的指针）。对列表进行排序，计算相邻元素的差异。
• 此时整个内存被分割成许多可能的结构。计算结构大小的直方图，删除任何无关紧要的值。
• 计算指针和结构体的地址差，这些指针所属的位置。对于每个结构大小，计算指针位移的直方图，再次删除任何不重要的值。
• 现在您有足够的信息来猜测结构类型或构建结构的有向图。找到该图的源节点和循环。您甚至可以像“列出“冷”内存区域”中那样可视化此图表。

Coredump 文件采用 elf 格式。仅需要数据段的开头和大小。为了简化过程，只需将其读取为线性文件，忽略结构。

Answer 2

一旦我看到它正在耗尽内存 - 内存使用量约为 1.5-2GB

这通常是错误循环误入歧途的最终结果。例如：

size_t size = 1;
p = malloc(size);
while (!enough_space(size)) {
  size *= 2;
  p = realloc(p, size);
}
// now use p to do whatever

如果 enough_space() 在某些情况下错误地返回 false，您的进程将快速增长以消耗所有可用内存。

仅使用智能指针

除非您控制链接到进程的所有代码，否则上述语句为假。错误循环可能位于 libc 内，或您不拥有的任何其他库内。

只有猜测才有帮助

就这样。叶夫根尼的答案有很好的起点来帮助你猜测。

Answer 3

普通的内存分配器不会跟踪进程的哪一部分分配了内存——毕竟，内存无论如何都会被释放，并且指针由客户端代码保存。如果内存确实泄漏了（即没有剩下指向它的指针），那么您几乎已经丢失并且正在查看一大块非结构化内存。

Answer 4

Valgrind 可能会发现几个可能的错误，并且值得对所有错误进行分析。您需要创建一个抑制文件，并像 --suppressions=/path/to/file.supp 一样使用它。对于 valgrind 标记的每个可能的错误，要么向抑制文件添加一个子句，要么更改您的程序。

您的程序在 Valgrind 中运行速度会变慢，因此事件发生的时间会有所不同，因此您无法确定是否看到错误发生。

valgrind 有一个名为 Alleyoop 的 GUI，但我用得不多。