Question

我的目标是从死后核心文件中弄清楚为什么特定进程消耗大量内存。有什么总结我可以得到某种方式？显而易见的是valgrind是不可能的，因为我无法实时访问该流程。

首先获得类似于/ proc /“pid”/ maps的输出会有所帮助，但

maintenance info sections

（如此处所述：GDB: Listing all mapped memory regions for a crashed process）在gdb中没有向我显示堆内存消耗。

info proc map

是一个选项，因为我可以使用完全相同的代码访问机器，但据我所知，它是不正确的。我的进程使用700MB-s，但看到的地图只占大约10 MB。我没有看到.so-s在

中可见

maintenance print statistics

你知道其他可能有用的命令吗？

我可以随时检测代码，但这并不容易。通过指针到达所有分配的数据就像大海捞针一样。

你有什么想法吗？

Answer 1

在gdb中进行此类事后调试不仅仅是一门科学，而是一门艺术。

在我看来，最重要的工具是能够编写在gdb内部运行的脚本。手册将向您解释。我发现它非常有用的原因是它允许你做一些事情，比如走数据结构和打印信息。

此处的另一种可能性是检测您的malloc版本 - 编写一个新的malloc函数，该函数保存有关正在分配的内容的统计信息，以便您可以查看这些事后验证。当然，您可以调用原始malloc来执行实际的内存分配工作。

对不起，我不能给你一个明显而简单的答案，只会在这里给你一个直接的解决方案 - 没有像valgrind这样的工具，这是一项非常艰苦的工作。

Answer 2

如果它的Linux你不必担心对你的malloc做统计。使用名为“memusage”的实用程序

用于示例程序（sample_mem.c），如下所示

#include<stdio.h>
#include<stdlib.h>
#include<time.h>

int main(voiid)
{
        int i=1000;
        char *buff=NULL;
        srand(time(NULL));

        while(i--)
        {
                buff = malloc(rand() % 64);
                free(buff);
        }

        return 0;
}

memusage的输出将是

$memusage sample_mem

Memory usage summary: heap total: 31434, heap peak: 63, stack peak: 80
         total calls   total memory   failed calls
 malloc|       1000          31434              0
realloc|          0              0              0  (nomove:0, dec:0, free:0)
 calloc|          0              0              0
   free|       1000          31434
Histogram for block sizes:
    0-15            253  25% ==================================================
   16-31            253  25% ==================================================
   32-47            247  24% ================================================
   48-63            247  24% ================================================

但是如果你写一个malloc wapper那么你可以在这么多malloc之后让你的程序coredump，这样你就可以得到线索。

Answer 3

您可以使用像log-malloc.c这样的简单工具，它可以在应用程序之前编译成LD_PRELOAD的共享库，并将所有malloc - 类型函数记录到文件中。至少它可能有助于缩小转储中的搜索范围。

使用gdb进行事后内存泄漏搜索（和分析）

3 个答案: