Как анализировать утечку памяти из 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%sn%s%s%s%sn", ,,,,,,,}' | 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. Может ли кто-нибудь сказать, как я могу конвертировать информацию о символах из двоичного формата?

11
c coredump gcore

2 ответов

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", ,,,,,,,}' | 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 должен относиться к утечке памяти i.E производные таблица виртуальных методов.

примечание: Я согласен, что анализ coredump не является лучшей практикой для поиска утечки памяти. Утечку памяти можно найти с различными статическими и динамическими инструментами как valgrind etc.

8

Я не думаю, что есть способ определить, вызывает ли процесс утечку памяти или непосредственно не смотрит на дамп ядра. Infact, нет вещи, называемой утечкой памяти как таковой, мы не можем сделать этот комментарий, не зная намерения программистов для написания кода. сказав это, вы можете получить представление, посмотрев на размер дампа. Вы можете создать несколько дампов, скажем, один после начального запуска и один после длительного запуска, и если вы видите огромную разницу в размере, можно наверное, что-то пошло не так. Но, опять же, память может быть использована для производственных целей.

для фактического анализа и отслеживания утечки памяти, необходимо, используя такие инструменты, как, memtrack, Valgrind и т. д., Чтобы добавить обертки над malloc и free, чтобы дать дополнительную информацию о каждой строкой alloc и Free.

обновление:

Как вы ищете шестигранник анализ, вот что я вижу: Каждая строка составляет 16 байт и повторяется в двух строках. То есть 32 байты кусок. 0x4D2-1234 в десятичной дроби. Итак, ваши данные есть. Возможно, что ваш один фрагмент alloc составляет 32 байта. Проверьте и распечатайте адрес в hex после каждого "new ()" и сравните, чтобы увидеть, наблюдаете ли вы разрыв в 32 байта, а затем он объясняет это.

2