问题如何分析coredump的内存泄漏

我想分析核心文件分析中的内存泄漏。

我编写了示例代码来注入内存泄漏并使用gcore命令生成核心文件。

#include <stdlib.h>
#include <unistd.h>
void fun()
{
  int *ptr = new int(1234);
}
int main()
{
  int i=0;
  while(i++<2500)
  {
    fun();
}
sleep(360);
return 0;
}

找到进程ID

ayadav@ajay-PC:~$ ps -aef |grep over  
ajay      8735  6016  0 12:57 pts/2    00:00:00 ./over  
ayadav    8739  4659  0 12:57 pts/10   00:00:00 grep over

并生成核心

ayadav@ajay-PC:~$ sudo gcore 8735
[sudo] password for ayadav:
0x00007fbb7dda99a0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
Saved corefile core.8735

我已经从核心文件中找到了常见的模式，如下所示（如stackoverflow另一个线程所示）有没有办法找到进程的哪个部分使用了大部分内存，只查看生成的核心文件？）

ayadav@ajay-PC:~$ hexdump core.6015 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr | head
6913 0000000000000000  
2503 0000002100000000  
2501 000004d200000000  
786 0000000000007ffc  
464  
125 1ccbc4d000007ffc  
 92 1ca7ead000000000  
 91 0000000200007ffc  
 89 0000000100007ffc  
 80 0000000100000000

怀疑以下两个地址

2503 0000002100000000  
2501 000004d200000000

核心文件有以下重复模式

0003560 0000 0000 0021 0000 0000 0000 04d2 0000  
0003570 0000 0000 0000 0000 0000 0000 0000 0000  
0003580 0000 0000 0021 0000 0000 0000 04d2 0000  
0003590 0000 0000 0000 0000 0000 0000 0000 0000  
00035a0 0000 0000 0021 0000 0000 0000 04d2 0000  
00035b0 0000 0000 0000 0000 0000 0000 0000 0000  
00035c0 0000 0000 0021 0000 0000 0000 04d2 0000  
00035d0 0000 0000 0000 0000 0000 0000 0000 0000  
00035e0 0000 0000 0021 0000 0000 0000 04d2 0000  
00035f0 0000 0000 0000 0000 0000 0000 0000 0000  
0003600 0000 0000 0021 0000 0000 0000 04d2 0000  
0003610 0000 0000 0000 0000 0000 0000 0000 0000  
0003620 0000 0000 0021 0000 0000 0000 04d2 0000  
0003630 0000 0000 0000 0000 0000 0000 0000 0000  
0003640 0000 0000 0021 0000 0000 0000 04d2 0000

但我不知道如何从命令如gdb info address或x访问它。谁能告诉我如何从二进制格式转换符号信息？

5605

2017-12-22 08:24

起源

可能重复核心转储文件分析 - gj13

可能重复如何分析程序的核心转储文件？ - skaffman

根据您的使用情况而定 new 我会说这是C ++，而不是C.但是你是 #includeING <stdlib.h>不是 <cstdlib>，所以我真的不知道你的程序用什么语言编写... - ace

答案:

1 - 可以使用核心转储评估内存泄漏。我已经采用了一个示例c ++示例：

class Base  
{  
public:  
    virtual void fun(){}  
    virtual void xyz(){}  
    virtual void lmv(){}  
    virtual void abc(){}  
};  

class Derived: public Base  
{  
public:  
    void fun(){}  
    void xyz(){}  
    void lmv(){}  
    void abc(){}  
};  

void fun()  
{  
    Base *obj  = new Derived();  
}  
int main()  
{  
    for(int i = 0; i < 2500;i++)
    {
        fun();
    }
    sleep(3600);
    return 0; 
}

2 - 使用gcore命令创建核心

3 - 从核心文件中搜索重复的模式。

ayadav@ajay-PC:~$ hexdump core.10639 | awk '{printf "%s%s%s%s\n%s%s%s%s\n", $5,$4,$3,$2,$9,$8,$7,$6}' | sort | uniq -c | sort -nr  | head
   6685 0000000000000000  
   2502 0000002100000000  
   2500 004008d000000000  
    726 0000000000007eff  
    502   
    125 2e4314d000007eff  
     93 006010d000000000  
     81 0000000100007eff  
     80 0000000100000000  
     73 0000000000000001

0000002100000000 和 004008d000000000 是重复的模式

4 - 检查每个qword是什么用的？

(gdb) info symbol ...
(gdb) x ...

例：

(gdb) info symbol 0x4008d000
No symbol matches 0x4008d000.
(gdb) info symbol 0x4008d0
vtable for Derived + 16 in section .rodata of /home/ayadav/virtual

5 - 可能最常见的vtable必须与内存泄漏有关，即派生vtable。

注意：我同意coredump分析不是查找内存泄漏的最佳做法。内存泄漏可以通过valgrind等不同的静态和动态工具找到。

2017-12-24 08:08

我喜欢Unix的思维方式，但我不得不说应该可以弄清楚核心文件中当前有哪些类型的分配......快速浏览一下Google之后核心分析仪来了 - nonsensickle

我认为没有办法确定进程是否导致内存泄漏或者不直接查看核心转储。事实上，没有任何称为内存泄漏的东西，我们无法在不知道程序员编写代码的意图的情况下做出评论。话虽如此，你可以通过查看核心转储的大小来获得一个想法。您可以生成多个转储，例如，一个在初始运行后，一个在长时间运行后，如果您看到大小的巨大差异，可以猜测可能会出现问题。但同样，记忆可以用于生产目的。

对于内存泄漏的实际分析和跟踪，应该使用memtrack，valgrind等工具在malloc上添加包装器，并免费提供有关每个alloc和free的额外信息。

更新：

当您正在寻找十六进制分析时，我可以看到以下内容：您的每一行都是16个字节，并以两行重复。这是一个块的32个字节。 0x4D2是十进制的1234。所以，你的数据就在那里。您的一个alloc块可能是32个字节。在每个'new（）'之后检查并打印十六进制的地址，并比较以查看是否观察到32字节的间隙然后解释它。

2017-12-22 09:56

嗨乔，回答说 stackoverflow.com/questions/8710404/...。可以从coredump中找到内存泄漏。我同意我可以使用像Valgrind这样的工具但是为了我的理解我想从核心文件中分析。 - Ajay yadav

根据您的要求更新答案。但我不认为这是调试内存泄漏的正确方法。 - joe

嗨，乔，非常感谢您的建议。是alloc block是32个字节的差距。 0x12c4010 0x12c4030 0x12c4050 0x12c4070 0x12c4090 0x12c40b0 0x12c40d0 0x12c40f0 0x12c4110 0x12c4130 0x12c4150 0x12c4170但我还有一个疑问我怎么能看到未引用的分配 - Ajay yadav

“事实上，没有一种称为内存泄漏的东西，我们无法在不知道程序员编写代码的意图的情况下做出这样的评论。”我会说这有点真实，但是如果有人动态分配内存，他们不再保留任何指针，就像在问题的例子中那样，那就是内存泄漏。 - Pulseczar

问题 如何分析coredump的内存泄漏

答案:

热门问题

问题如何分析coredump的内存泄漏