valgrind - Trova perdita di memoria in una libreria condivisa

Ho bisogno di sapere come trovare le perdite di memoria in una libreria condivisa che verrà caricata su un binario di rilascio. Intendo la libreria condivisa che ho creato con l'opzione -g ma il file binario che carica la libreria condivisa non è costruito con l'opzione -g.valgrind - Trova perdita di memoria in una libreria condivisa

Ottengo il rapporto di perdita come segue.

==739== at 0x4A05809: malloc (vg_replace_malloc.c:149) 
==739== by 0x84781B1: ??? 
==739== by 0x87507F5: ??? 
==739== by 0x874CF47: ??? 
==739== by 0x874E657: ??? 
==739== by 0x874F7C2: ??? 
==739== by 0x8779C0C: ???

Per favore fatemi sapere come ottenere la traccia dello stack della perdita dalla libreria condivisa?

fonte

2012-09-27 Naga

Supponendo che la perdita provenga realmente dalla libreria condivisa, non penso che il problema sia la mancanza di debug nell'esecuzione principale.

Più probabilmente il tuo problema è che l'eseguibile sta scaricando la libreria condivisa chiamando dlclose prima che finisca. Ciò significa che quando valgrind arriva per verificare la presenza di perdite, tutte le informazioni sui simboli per la libreria sono scomparse poiché la libreria non è più caricata.

Se è possibile ricostruire l'eseguibile, la soluzione più semplice potrebbe essere quella di interromperlo temporaneamente chiamando lo dlclose in modo che la libreria rimanga caricata fino alla fine.

Se non è possibile farlo, allora provare a utilizzare LD_PRELOAD di mantenere la libreria caricata, in questo modo:

LD_PRELOAD="/path/to/library.so" valgrind my-executable

che si spera ingannare il linker dinamico in mantenendo la libreria caricata anche dopo che è stato chiuso .

fonte

2012-10-30 10:02:31 TomH

C'era una patch che forniva un'opzione per disabilitare lo scaricamento dei simboli dopo dlclose. La patch funziona e l'ho usata molte volte. Ma la patch era sulla vecchia versione e immagino che ora sia marcia. https://bugs.kde.org/show_bug.cgi?id=79362 – k0n3ru

@ Tom: vorrei far notare che la soluzione "ometti dlclose" può causare molti falsi positivi. Se ci sono oggetti nella pila che distruggono elementi, che erano nell'heap, allora questi sono stati mostrati nell'output come perdite, perché dlclose avrebbe fatto il destroy in primo luogo. – newhouse

E il secondo non funziona bene, se valgrind è a 64 bit, ma si esegue il debug 32 – newhouse

Come la risposta precedente suggerisce, questo è perché hai chiuso le tue librerie prima che il programma termini e quindi le informazioni sui simboli non sono disponibili per valgrind.

L'utilizzo di LD_PRELOAD non ha funzionato per me; Ora ho due build; uno che esplicitamente non chiama dlclose(); su questa build, valgrind riporta correttamente le informazioni sul numero di riga come ci si aspetterebbe con il collegamento dinamico.

fonte

2013-02-18 06:57:31 Doug

valgrind - Trova perdita di memoria in una libreria condivisa

risposta

Problemi correlati