Diagnosi dei deadlock nel programma Win32

Question

Quali sono i passaggi e le tecniche per eseguire il debug di un apparente blocco dovuto a un deadlock in un processo di produzione Win32.Ho sentito che WinDbg può essere utilizzato per questo scopo, ma potresti fornire suggerimenti chiari su come farlo?

Answer 1

Questo inviare dovrebbe aiutarti a iniziare con le varie opzioni.. Controlla i post contrassegnati con Debug..

Un altro articolo utile su debugging dei deadlock..

Answer 2

Il debug di un vero deadlock è in realtà piuttosto semplice, se si ha accesso all'origine e a un dump della memoria (o una sessione di debug in tempo reale).

Tutto quello che fai è guardare i thread e trovare quelli che sono in attesa di qualche tipo di risorsa condivisa (ad esempio in attesa in WaitForSingleObject).In generale, da lì si tratta di capire quali due o più thread si sono bloccati a vicenda, e poi devi solo capire quale ha rotto la gerarchia dei blocchi.

Se non riesci a capire facilmente quali thread sono bloccati, utilizza il metodo mostrato in questo post qui per tracciare la catena di blocco per ogni thread.Quando entri in un loop, i thread nel loop sono quelli che sono in stallo.

Answer 3

Se sei molto pigro, puoi installare Application Verifier, quindi aggiungere il modulo e selezionare solo "lucchetti" dal test di base.quindi puoi eseguire la tua applicazione con qualsiasi debugger.
se si verifica uno stallo in una sezione critica, trova subito il motivo.

Answer 4

Che linguaggio/IDE stai utilizzando?

In .Net è possibile visualizzare i thread di un'applicazione:Debug->Windows->Thread o Ctrl+Alt+H

Answer 5

Il debug dei deadlock può essere complicato.Di solito eseguo una sorta di registrazione e vedo dove si ferma il registro.Accedo a un file o alla console di debug utilizzando OutputDebugString().

Answer 6

La cosa migliore è iniziare aggiungendo istruzioni di logging.Generalmente consiglierei solo le risorse condivise che sono in stallo, ma anche aggiungerle in generale potrebbe indicare situazioni o aree di codice che non ti aspettavi.Il tanto pubblicizzato problema del database stackoverflow.com in realtà si è rivelato essere log4net!Il team di StackOverflow non ha mai sospettato log4net e solo esaminando il logging (ironicamente) lo ha dimostrato.Inizialmente rinuncerei a qualsiasi strumento complicato, ad esempio WinDgb, poiché il loro utilizzo non è molto intuitivo IMHO.