2013-04-19 8 views
7

Ho un software buggy (memoria trapelata). Come prova, ho 1 GB di file core.dump. La dimensione dell'heap è 900 MB, quindi, ovviamente, qualcosa alloca, ma non libera la memoria.gdb, memoria di dump, salvataggio dell'output formattato in un file

Quindi, ho un'area di memoria da esaminare in questo modo.

(gdb) x/50000s 0x200000000 

Tuttavia, questo è difficile da indovinare solo ad occhio nudo, che oggetto o struct non viene liberato. La mia idea di tracciare è, "Salvare l'output formattato gdb in un file ed eseguire una corrispondenza di modello per vedere quale stringa magica si presenta di più." Quindi, ecco la mia domanda:

Come posso salvare l'output del seguente comando in un file di testo, in modo che possa scrivere un analizzatore?

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

Grazie per qualsiasi aiuto.

risposta

7

Come posso salvare l'output del seguente comando in un file di testo, in modo che possa scrivere un analizzatore?

(gdb) x/10000000s 0x20000000 

Che in realtà è abbastanza semplice:

(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, godetevi la vostra uscita nelle gdb.txt.

Ho un buggy (memoria trapelata) software. ... "Salva l'output formattato gdb in un file ed esegui una corrispondenza di modello per vedere quale stringa magica si presenta di più."

Questa idea è piuttosto improbabile che dia risultati soddisfacenti. Considerare:

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". 
} 

Anche se si potrebbe effettivamente "vedere stringa magica che si apre il più", scoprirete che siete che perde tutte le stringhe; ma sono non il problema, la perdita "v" è il problema.

Quindi ciò che si vuole veramente è costruire un grafico di cui le regioni assegnate puntano ad altre regioni allocate e trovare una "radice" di quel grafico. Questo è quasi impossibile da fare a mano.

Quindi cosa è più probabilmente per aiutarti a trovare la perdita di memoria (s)? Fortunatamente, ci sono un sacco di strumenti in grado di risolvere questo problema per voi:

+0

C'è anche un comando dedicato discarica di gdb. Vedi anche: https://sourceware.org/gdb/onlinedocs/gdb/Dump_002fRestore-Files.html – Alex

16

È possibile utilizzare la funzione di "dump" di gdb, vedi: https://sourceware.org/gdb/onlinedocs/gdb/Dump_002fRestore-Files.html

Per esempio:

dump binary memory result.bin 0x200000000 0x20000c350 

questo vi darà una pianura dump binario del file int result.bin. È inoltre possibile utilizzare il seguente per scaricare in formato esadecimale:

dump ihex memory result.bin 0x200000000 0x20000c350 

utilizzando il comando discarica è molto più chiara che usare l'hack di registrazione gdb (che anche non ha funzionato per me in qualche modo).

0

è possibile scrivere semplice lkm lo farà

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); 

ei dati verranno visualizzati nel registro così scrivere

enter code here 
dmesg 
+0

Puoi semplicemente usare/dev/kmem o/proc/kcore per farlo. Furthurmore, questo non risponde alla domanda. – minmaxavg

Problemi correlati