Wie Speicherleck von Coredump zu analysieren

Question

Ich möchte ein Speicherleck von Kerndateianalyse analysieren.

Ich habe Beispielcode geschrieben, um Speicherverlust zu injizieren und Core-Datei mit Gcore-Befehl zu generieren.

#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; 
} 

die ID-Prozess finden

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 

und erzeugt Kern

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 

Ich habe gemeinsame Muster von Core-Datei wie folgt zu finden (wie vorgeschlagen auf Stackoverflow ein anderer Thread Is there a way to locate which part of the process used the most of the memory, only looking at a generated core file?)

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 

unter zwei Adressen ein vermutetes

2503 0000002100000000 
2501 000004d200000000 

Systemdatei haben nach wiederholten Muster

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 

Aber ich habe nicht viel Ahnung, wie ich es von Befehl wie GDB info Adresse oder x zugreifen können. Kann jemand sagen, wie ich Symbolinformationen vom binären Format umwandeln kann?

Answer 1

1 - Speicherlecks können mit einem Core Dump ausgewertet werden. Ich habe eine Probe C++ Beispiel genommen:

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 - Such wiederholendes Muster von Core-Datei - einen Kern mit gcore Befehl

3 Erstellt.

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 und 004008d000000000 werden Muster wiederholt

4 - Überprüfen Sie jede qword ist, was mit?

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

Beispiel:

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

5 - Wahrscheinlich am häufigsten VTable müssen Speicherleck d.h Abgeleitet VTable beziehen.

Hinweis: Ich stimme zu Coredump-Analyse ist nicht die beste Methode, Speicherverlust zu finden. Speicherlecks können mit verschiedenen statischen und dynamischen Tools wie Valgrind usw. gefunden werden.

Answer 2

Ich glaube nicht, dass es einen Weg gibt zu identifizieren, ob ein Prozess Speicherverlust verursacht oder nicht direkt auf den Core-Dump schauen. Tatsächlich gibt es kein Ding, das Speicherleck als solches genannt wird, wir können diesen Kommentar nicht machen, ohne die Absicht des Programmierers zu kennen, den Code zu schreiben. Nachdem Sie das gesagt haben, können Sie sich eine Vorstellung machen, indem Sie sich die Größe des Core Dump ansehen. Sie können mehrere Speicherauszüge erzeugen, einen nach dem ersten Lauf und einen nach einem längeren Lauf, und wenn Sie einen großen Unterschied in der Größe sehen, kann man vermuten, dass etwas schief gehen könnte. Aber wieder könnte die Erinnerung für produktive Zwecke verwendet werden.

Für die tatsächliche Analyse und Verfolgung von Speicherverlust, sollte man Werkzeuge wie, memtrack, valgrind usw. Wrapper über malloc und kostenlos hinzufügen, um zusätzliche Informationen über jede Alloc und frei zu geben.

Update:

Wie Sie für die Hex-Analyse suchen, hier ist das, was ich sehen kann: Ihre jede Zeile 16 Bytes ist und in zwei Zeilen wiederholt. Das sind 32 Bytes pro Chunk. 0x4D2 ist 1234 in Dezimal. Also, deine Daten sind da. Es könnte möglich sein, dass Ihr One Alloc Chunk 32 Bytes ist. Überprüfen und drucken Sie die Adresse in Hex nach jedem neuen() und vergleichen Sie, um zu sehen, ob Sie eine Lücke von 32 Bytes beobachten und dann erklärt es.