2010-04-02 9 views
21

Sto cercando di esaminare lo stato dell'heap C/C++ da gdb su Linux amd64, c'è un modo carino per farlo?Esaminare le statistiche della memoria heap in C/C++ in gdb

Un approccio che ho provato è "chiamare mallinfo()" ma sfortunatamente non riesco a estrarre i valori che voglio dato che gdb non gestisce correttamente il valore restituito.

Non riesco facilmente a scrivere una funzione da compilare nel file binario per il processo a cui sono collegato, quindi posso semplicemente implementare la mia funzione per estrarre i valori chiamando mallinfo() nel mio codice questo modo. C'è forse un trucco intelligente che mi permetterà di fare questo al volo?

Un'altra opzione potrebbe essere quella di individuare l'heap e attraversare le intestazioni malloc/elenco libero; Apprezzerei qualsiasi suggerimento su dove potrei iniziare a trovare la posizione e il layout di questi.

Ho cercato Google e ho letto il problema per circa 2 ore e ho imparato alcune cose affascinanti ma non ho ancora trovato quello di cui ho bisogno.

+1

Che cosa è necessario sapere sullo stato? Che tipo di statistiche hai bisogno di sapere? –

+0

La dimensione dell'heap, la quantità utilizzata e l'importo gratuito sono un buon inizio –

+0

Cosa non funziona correttamente gdb? – leedm777

risposta

20

@fd - il RedHat bug ha avuto la tua risposta.

La funzione mallinfo è stata deprecata e non verrà aggiornata. Una vera API delle statistiche di query è TDB. Oggi hai malloc_stats e malloc_info. Non riesco a trovare alcuna documentazione su nessuno dei due, ma ecco cosa ti danno.

È abbastanza vicino a quello che ti serve?

(gdb) call malloc_stats() 
Arena 0: 
system bytes  =  135168 
in use bytes  =   96 
Total (incl. mmap): 
system bytes  =  135168 
in use bytes  =   96 
max mmap regions =   0 
max mmap bytes =   0 

(gdb) call malloc_info(0, stdout) 
<malloc version="1"> 
<heap nr="0"> 
<sizes> 
<unsorted from="1228788" to="1229476" total="3917678" count="3221220448"/> 
</sizes> 
<total type="fast" count="0" size="0"/> 
<total type="rest" count="3221220448" size="3917678"/> 
<system type="current" size="135168"/> 
<system type="max" size="135168"/> 
<aspace type="total" size="135168"/> 
<aspace type="mprotect" size="135168"/> 
</heap> 
<total type="fast" count="0" size="0"/> 
<total type="rest" count="3221220448" size="3917678"/> 
<system type="current" size="135168 
/> 
<system type="max" size="135168 
/> 
<aspace type="total" size="135168"/> 
<aspace type="mprotect" size="135168"/> 
</malloc> 
+0

Buon lavoro, ho trovato malloc_stats() la scorsa notte e l'ho usato molto bene nei miei test precedenti oggi. Ho anche incontrato glibc wiki di sourceware che indicava il live di Ulrich Drepper con questo post - http: //udrepper.livejournal.com/20948.html - dall'aprile 2009 descrivendo la sostituzione a mallinfo (tra le altre cose) ma devo ancora provarlo. Grazie per aver pubblicato l'output, sembra molto interessante. +1 –

+0

A proposito, hai trovato qualche documento per malloc_info()? Il primo argomento descrive il numero dell'arena? Vedo il nell'output, e nel mio test malloc_stats() mostra le statistiche per un certo numero di arene (a parte: mallinfo() sembra anche essere limitato in quanto mostra solo informazioni dall'arena zero-th, che è il motivo per cui il mio i test di esso non corrispondevano all'utilizzo della memoria che ho visto riportato in alto, inoltre, nessuna singola statistica dell'arena è cresciuta abbastanza da colpire il bug cui ho fatto riferimento prima). –

+0

Non riesco a trovare documenti per malloc_info(). Secondo la fonte, 'if (options! = 0) restituisce EINVAL' - http://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=558e8bab0ab3808ec9f5b569ca62863ef4651b27; hb = testa # l6323. Sembra che iterates attraverso tutte le arene. – leedm777

3

Se è possibile modificare il codice:

#include <malloc.h> 
#include <stdio.h> 

void dumpMallinfo(void) { 
    struct mallinfo m = mallinfo(); 
    printf("uordblks = %d\nfordblks = %d\n", m.uordblks, m.fordblks); 
} 

In GDB, è possibile call dumpMallinfo().

+0

Come ho affermato nella domanda, non posso, tuttavia questa è una tecnica utile. +1 (questo era uno degli approcci rivelati dalle 2 ore di Google) –

+1

Trovato un po 'di informazioni utili su mallinfo(); non sembra pronto per 64 bit. La struttura restituita, composta da membri int, non gestisce dimensioni in byte superiori a 4 GB. Non ho trovato alcuna prova di una correzione per questo, anche se ho trovato sia un rapporto sui bug Debian che RedHat entrambi chiusi come NOTABUG/WONTFIX. –

+0

Per reiterare il mio commento sull'altra risposta di dave qui sotto: mallinfo() sembra anche essere limitato in quanto mostra solo informazioni dall'arena zero-th, motivo per cui i miei test non corrispondono all'utilizzo della memoria che ho visto riportato da superiore; inoltre, nessuna singola statistica dell'arena è cresciuta abbastanza da colpire l'errore che ho citato prima. malloc_stats() ha mostrato informazioni da tutte le arene. –

Problemi correlati