Come individuare una mancata corrispondenza libera/eliminazione riportata da Valgrind in un programma con multithreading?

Question

Ecco il report Valgring:

==14546== Thread 5: 
==14546== Invalid free()/delete/delete[] 
==14546== at 0x490555D: free (vg_replace_malloc.c:235) 
==14546== by 0x3BF7EFAA8F: free_mem (in /lib64/tls/libc-2.3.4.so) 
==14546== by 0x3BF7EFA581: __libc_freeres (in /lib64/tls/libc-2.3.4.so) 
==14546== by 0x4802676: _vgw_freeres (vg_preloaded.c:62) 
==14546== Address 0x4DC4EE0 is not stack'd, malloc'd or (recently) free'd 

Come posso sapere quale filo è come il numero di thread di esecuzione varia da una all'altra? L'aiuto assigning names to my threads sarà qui?

EDIT: Non penso che lo sarà, come indicato nella sezione DRD del manuale.

Sto usando valgrind-3.1.1 su Linux Enterprise AS4 Red Hat.

Answer 1

ho finalmente trovato la spiegazione per questo: il mio eseguibile unit-test era legato ad un [terzo] biblioteca didn usare L'ho ricollegato senza quella libreria e il problema è andato via.

Inoltre, l'errore è stato rilevato in __libc_freeres(), una funzione della libb di gnu che libera risorse alla fine dell'esecuzione. Il problema potrebbe risiedere nella libreria o negli glibc.
È possibile utilizzare il seguente Valgrind Linux-specific option per evitare questo errore: --run-libc-freeres=no. Si noti che questo può rendere meno efficiente il rilevamento delle perdite.

Answer 2

È possibile utilizzare la macro DRD_GET_DRD_THREADID per visualizzare gli ID di thread all'avvio del thread. Puoi anche dare un nome nella stampa per aiutare. Vedere l'EDIT DRD Manual

Forse non sono specifici qui .. ma credo che è necessario collegare in alcune librerie valgrind quando si genera una versione di debug del codice (magari con un opzione di compilazione o qualcosa del genere) . È possibile utilizzare DRD_GET_DRD_THREADID all'interno del thread e ottenere un nome assegnato all'avvio, quindi è possibile scrivere tali informazioni su un file o sulla console. Non c'è modo di dire a DRD di stampare il nome che non penso, quindi devi usare una combo.

Answer 3

È probabile che si stia liberando una variabile globale (l'indirizzo: 0x4DC4EE0 è molto vicino a dove i globals vivono per impostazione predefinita su Linux/x86_64).

Eseguire il programma in GDB, quindi fare info symbol 0x4DC4EE0 e GDB dovrebbe dirvi tutto ciò che è necessario sapere.

Aggiornamento:
Valgrind 3.6 segnala effettivamente il simbolo globale. Ad esempio, dato questo programma buggy:

#include <stdlib.h> 

int x; 

int main() 
{ 
    free(&x); 
    return 0; 
} 

Valgrind 3.6 rapporti:

==18731== Invalid free()/delete/delete[] 
==18731== at 0x4C240E8: free /tmp/vg/coregrind/m_replacemalloc/vg_replace_malloc.c:394 
==18731== by 0x4004AA: main /home/t.c:7 
==18731== Address 0x60089c is 0 bytes inside data symbol "x"