Gdb, Speicherauszug, speichern formatierte Ausgabe in eine Datei

Question

Ich habe eine fehlerhafte (Speicher durchgesickert) Software. Als Beweis habe ich 1 GB core.dump Datei. Heap-Größe ist 900MB, so offensichtlich, etwas zuweist, aber nicht den Speicher frei.

Also, ich habe eine Speicherregion so zu untersuchen.

(gdb) x/50000s 0x200000000 

Dies ist jedoch nur mit bloßem Auge schwer zu erraten, welches Objekt oder welche Struktur nicht freigegeben ist. Meine Idee zu verfolgen ist, "Speichern gdb formatierte Ausgabe in eine Datei, und führen Sie eine Musterübereinstimmung, um zu sehen, welche magische Zeichenfolge am meisten kommt." Also, hier ist meine Frage:

Wie kann ich die Ausgabe des folgenden Befehls in eine Textdatei speichern, so dass ich einen Analysator schreiben kann?

(gdb) x/10000000s 0x20000000 <-- I need this output into a file 

Vielen Dank für jede Hilfe.

Answer 1

Wie kann ich die Ausgabe des folgenden Befehls in eine Textdatei speichern, so dass ich einen Analysator schreiben kann?

(gdb) x/10000000s 0x20000000 

Das ist eigentlich ganz einfach ist:

(gdb) set height 0 # prevent GDB from stopping every screenfull 
(gdb) set logging on # GDB output is now also copied into gdb.txt 
(gdb) x/10000000s 0x20000000 
(gdb) quit 

Voila, genießen Sie den Ausgang in gdb.txt.

Ich habe eine fehlerhafte (Speicher durchgesickert) Software. ... "Speichern Sie die gdb-formatierte Ausgabe in eine Datei und führen Sie eine Musterübereinstimmung aus, um zu sehen, welche magische Zeichenkette am meisten auftaucht."

Diese Idee ist ziemlich unwahrscheinlich, um befriedigende Ergebnisse zu liefern. Bedenken Sie:

void some_function() { 
    std::vector<string> *v = new std::vector<string>(); 
    // code to insert and use 1000s of strings into "v". 
    return; // Oops: forgot to delete "v". 
} 

Auch wenn Sie effektiv „magische String sehen, dass die meisten aufkommt“ könnte, werden Sie feststellen, dass Sie alle Fäden sind undicht; aber sie sind nicht das Problem, undichte "v" ist das Problem.

Also was Sie wirklich wollen, ist ein Diagramm zu erstellen, von dem zugewiesene Regionen auf andere zugewiesene Regionen zeigen, und eine "Wurzel" dieses Diagramms finden. Dies ist fast unmöglich per Hand zu machen.

Also was ist mehr wahrscheinlich, um Ihnen zu helfen, das Speicherleck (s) zu finden? Glücklicherweise gibt es viele von Tools, die dieses Problem für Sie lösen können:

• Valgrind,
• Google Haufen Leck checker,
• jemalloc,
• ... etc. etc.

Answer 2

Sie könnten die "Dump" -Funktion von gdb verwenden, siehe: https://sourceware.org/gdb/onlinedocs/gdb/Dump_002fRestore-Files.html

Für Ihr Beispiel:

dump binary memory result.bin 0x200000000 0x20000c350 

Dies gibt Ihnen eine einfache binäre Dump int Datei result.bin.

dump ihex memory result.bin 0x200000000 0x20000c350 

Mit der Dump-Befehl ist viel klarer als mit der GDB Logging Hack (die auch nicht für mich irgendwie nicht funktioniert): Sie können auch die folgenden dump es in Hex-Format verwenden.

Answer 3

können Sie einfach LKM schreiben tun, dass

lkm: 
#include <linux/kernel.h> 
#include <linux/module.h> 

int *ptr=(int*)0Xc18251c0; //the address you want to read from kernel space 
int module_i(void) 
{ 
printk("%d\n",*ptr); 
} 
module_init(module_i); 

und die Daten werden in Flog angezeigt, so

enter code here 
dmesg