Tracciamento del danneggiamento della memoria su un server Linux di produzione

Question

Ragazzi, potreste consigliare uno strumento per individuare un danneggiamento della memoria su un server multithread di produzione creato con C++ e funzionante con Linux x86_64?Attualmente sto affrontando il seguente problema:ogni diverse ore il mio server si blocca con un segfault e il core dump mostra che si verifica un errore in malloc/calloc, il che è sicuramente un segno che la memoria è danneggiata da qualche parte.

In realtà ho già provato alcuni strumenti senza molta fortuna.Ecco la mia esperienza finora:

• Valgrind è un ottimo strumento (direi anche il migliore) ma rallenta troppo il server rendendolo inutilizzabile in produzione.L'ho provato su uno stage server e mi ha davvero aiutato a trovare alcuni problemi relativi alla memoria, ma anche dopo averli risolti continuo a riscontrare arresti anomali sul server di produzione.Ho eseguito il mio stage server con Valgrind per diverse ore ma non sono ancora riuscito a individuare errori gravi.

• Si dice che ElectricFence sia un vero e proprio divoratore di memoria, ma non sono nemmeno riuscito a farlo funzionare correttamente.Si segnala quasi immediatamente sullo stage server in posti strani e casuali in cui Valgrind non ha mostrato alcun problema.Forse ElectricFence non supporta bene il threading?...Non ne ho idea.

• DUMA - stessa storia di ElectricFence ma anche peggio.Mentre EF ha prodotto core dump con backtrace leggibili, DUMA mi mostra solo "?????"(e sì, il server è sicuramente creato con il flag -g)

• dmalloc: ho configurato il server per utilizzarlo al posto delle routine malloc standard, tuttavia si blocca dopo diversi minuti.Allegare un gdb al processo rivela che è bloccato da qualche parte in dmalloc :(

Sto gradualmente diventando pazzo e semplicemente non so cosa fare dopo.Ho i seguenti strumenti da provare:mtrace, mpatrol ma forse qualcuno ha un'idea migliore?

Apprezzerei molto qualsiasi aiuto su questo problema.

Aggiornamento: Sono riuscito a trovare la fonte del bug.Tuttavia l'ho trovato sullo stage server e non su quello di produzione utilizzando helgrind/DRD/tsan: si è verificata una corsa di dati tra diversi thread che ha provocato il danneggiamento della memoria.La chiave era utilizzare le opportune soppressioni di Valgrind poiché questi strumenti mostravano troppi falsi positivi.Tuttavia non so davvero come questo possa essere scoperto sul server di produzione senza rallentamenti significativi...

Answer 1

Gente, sono riuscito a trovare la fonte del bug.Tuttavia l'ho trovato sullo stage server utilizzando helgrind/DRD/tsan: si è verificata una corsa di dati tra diversi thread che ha provocato il danneggiamento della memoria.La chiave era usare corretto soppressioni di valgrind poiché questi strumenti mostravano troppi falsi positivi.Tuttavia non so davvero come questo possa essere scoperto sul server di produzione senza rallentamenti significativi...

Answer 2

Si, C / C ++ problemi di corruzione della memoria sono duri. Ho anche usato diverse volte valgrind, a volte è rivelato il problema e, a volte no.

Mentre l'esame di uscita valgrind non tendono a ignorare il suo risultato troppo veloce. A volte dopo un tempo considerevole trascorso, vedrai che valgrind ti ha dato l'indizio sul primo posto, ma l'ignorò.

Un altro consiglio è quello di confrontare il codice cambia dal rilascio stabile precedentemente conosciuto. Non è un problema se si utilizza una sorta di sistema di controllo delle versioni di origine (ad esempio svn). Esaminare tutte le funzioni relative di memoria (ad esempio memcpy, memset, sprintf, nuova, cancellare / delete []).

Answer 3

compilare il programma con gcc 4.1 e la -fstack-protector-all interruttore. Se la corruzione della memoria è causata da pila smashing questo dovrebbe essere in grado di rilevarlo. Potrebbe essere necessario giocare con alcuni dei parametri aggiuntivi di SSP.

Answer 4

Hai provato -fmudflap ? (Scorrere verso l'alto poche righe per visualizzare le opzioni disponibili).

Answer 5

si può provare IBM purificare, ma temo che non è opensource ..

Answer 6

I Google perftools --- che è open source --- può essere di aiuto, vedere la mucchio checker documentazione .

Answer 7

Prova questo: http://www.hexco.de/rmdebug/ Ho usato estensivamente, la sua ha un basso impatto nelle prestazioni (per lo più impatti quantità di RAM), ma l'algoritmo di allocazione è lo stesso. La sua comprovata sempre sufficiente per trovare eventuali bug di allocazione. Il vostro programma andrà in crash non appena si verifica l'errore, e avrà un registro dettagliato.

Answer 8

Non sono sicuro se avrebbe catturato la vostra particolare bug, ma la variabile d'ambiente MALLOC_CHECK_ ( pagina man malloc ) si accende una verifica supplementare per l'attuazione malloc Linux di default, e in genere non ha un costo significativo runtime.