Strategie per trovare Heisenbugs

Question

Attualmente sono di nuovo nella situazione in cui devo trovare la causa di un Bug che quasi mai accade quando un debugger è in esecuzione (probabilmente alcune condizioni di competizione). Le uniche cose che posso pensare di trovarlo sono:

1. Aggiungere stampe di debug e asserzioni al codice che mi dicono cosa sta succedendo senza un debugger.
2. Passa attraverso il codice e pensa a tutte le linee e ai possibili effetti collaterali che potrebbe avere.

Tutto sommato, questo è molto frustrante. Quali sono le tue strategie ed esperienze con questo tipo di bug?

Modifica: Sto usando Visual C++ 2005, ma penso che la domanda applichi molti (tutti) linguaggi e ambienti di sviluppo.

Answer 1

Quando tutte le tecniche sono finite e BoundsCheckers o RationalPurify non sono di aiuto. Di solito uso una tecnica molto stupida. L'abbiamo scoperto al primo anno di università. In russo è chiamato molto approssimativo.

Quindi, sto iniziando scegliendo il blocco/modulo sospetto che non riesce nell'ambiente multithread. Se è impossibile, la struttura del programma viene rielaborata.

Quando il modulo è selezionato, sto commentando piccoli blocchi di codice finché l'eccezione non scompare. Ciò consente di individuare le cause esatte (ad esempio le condizioni di gara). Se in questa fase puoi dire cosa non va, allora è grandioso.

In caso contrario, la stessa tecnica applicata per rilevare la pre-condizione dell'errore, quindi sto commentando il codice che prevede il blocco colpevole.

Answer 2

Ho scoperto che il rilascio di lanuggine sul mio codice C/C++/Java e l'assicurazione di correggere ogni avvertenza offerta ha comportato la scomparsa di queste condizioni di gara. Ma questa non è una soluzione. Mai codice per coincidenza. Devi capire cosa hai risolto e perché ha risolto il problema.

credo che si trattava di K (& & ||) R che ha dichiarato che i messaggi di logging copiose hanno fatto di più per aiutarli a eseguire il debug di codice di qualsiasi debugger - specialmente in ambienti multi-threaded, ma è necessario citazione.

Guardare attentamente una traccia molto dettagliata di tutte le attività che portano al bug che si alza veramente aiuta molto.

Answer 3

Se si riesce a identificare il punto (s) in cui il problema è il primo visibile (non quando è causata, ovviamente), sollevare un'eccezione lì e usare Process Dumper per ottenere una discarica per il debug post-mortem.

Eseguire i file binari di rilascio all'esterno dell'IDE e collegare successivamente il debugger. Ciò evita l'heap speciale e gli altri flag abilitati a funzionare all'interno del debugger.

Se avete qualche idea su dove si trova il bug, estraetelo in un'app di test minimamente sufficiente che vi martella il più possibile, provate a testarlo alla distruzione. Ancora una volta, collega il debugger solo dopo che il codice è attivo e funzionante per evitare molti effetti collaterali specifici di Debugger.

Opzioni di ispezione: creare con /W4 solo per assicurarsi che non sia stato notato nulla di ovvio.Controlla il codice e gli avvisi per i cast in stile C o reinterpret_cast nel caso in cui qualcuno abbia respinto un messaggio di errore o un messaggio di errore.