Come eseguire il debug di un deadlock?

Question

Oltre a questo non so se riesco a riprodurlo ora che è successo (ho usato questa particolare applicazione per una settimana o due ora senza problemi), supponendo che sto eseguendo la mia applicazione nel debugger VS , come devo fare per mettere a punto un deadlock dopo che è successo? Ho pensato che avrei potuto ottenere gli stack di chiamata se avessi messo in pausa il programma e quindi vedere dove erano i diversi thread quando è successo, ma facendo clic su pause ho gettato Visual Studio in un deadlock anche fino a quando ho ucciso la mia applicazione.

C'è qualche modo oltre che sfogliare il mio albero dei sorgenti per trovare potenziali problemi? C'è un modo per arrivare alle pile di chiamate una volta che il problema si è verificato per vedere dove si trova il problema? Eventuali altri strumenti/suggerimenti/trucchi che potrebbero aiutare?

Answer 1

Quello che hai fatto è stato il modo corretto. Se Visual Studio si blocca anche, ciò accade di tanto in tanto. È solo sfortuna, a meno che non ci sia un altro problema.

Non è necessario eseguire l'applicazione nel debugger per eseguirne il debug. Esegui normalmente l'applicazione e, se si verifica il deadlock, puoi allegare VS in un secondo momento. Ctrl + Alt + P, selezionare il processo, selezionare il tipo di debugger e fare clic su allegare. L'utilizzo di un diverso set di tipi di debugger può ridurre il rischio di arresti anomali di VS (soprattutto se non si esegue il debug del codice nativo)

Un deadlock richiede 2 o più thread.Probabilmente conosci il primo (probabilmente il tuo thread dell'interfaccia utente) da quando hai notato il deadlock nella tua applicazione. Ora hai solo bisogno di trovare l'altro. Con la conoscenza dell'architettura, dovrebbe essere facile da trovare (ad esempio, quello che altri thread utilizzano le stesse serrature, interagire con l'interfaccia utente, ecc)

Se VS non funziona affatto, si può sempre usare windbg . Scarica qui: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Answer 2

È possibile utilizzare programmi diversi, come Intel (R) Ispettore parallelo:
http://software.intel.com/en-us/intel-parallel-inspector/

Tali programmi in grado di mostrare i luoghi nel codice con i potenziali deadlock. Tuttavia dovresti pagare per questo, o usarlo solo per il periodo di valutazione. Non so se ci sono strumenti gratuiti come questo.

Answer 3

mi piacerebbe provare diversi approcci nel seguente ordine:

-In primo luogo, ispezionare il codice alla ricerca di violazioni di filo di sicurezza, facendo in modo che le vostre regioni critiche non chiamano altre funzioni che a sua volta provare per bloccare una regione critica.

-Utilizzare qualsiasi strumento su cui è possibile mettere le mani per visualizzare l'attività del thread, utilizzo uno script interno perl che analizza un log del sistema operativo creato e visualizza graficamente tutti gli switch di contesto e mostra quando un thread viene preventivamente eliminato.

-Se non è possibile trovare uno strumento valido, eseguire alcune registrazioni per vedere gli ultimi thread in esecuzione prima del deadlock. Questo ti darà un indizio su dove il problema potrebbe essere causato, aiuta se i meccanismi di blocco hanno nomi univoci, come se un oggetto ha il suo thread, crea un semaforo o mutex dedicato solo per gestire quel thread.

Spero che questo aiuti. In bocca al lupo!

Answer 4

Proprio come ovunque, non ci sono strumenti "Silver bullet" per catturare tutti i deadlock. Si tratta della sequenza in cui diversi thread acquisiscono risorse, quindi il tuo compito è scoprire dove è stato violato l'ordine. Di solito Visual Studio o altri debugger forniscono tracce di stack e sarai in grado di scoprire dove si trova la discrepanza. DevPartner Studio fornisce analisi di deadlock ma l'ultima volta che ho controllato c'erano troppi falsi positivi. Alcuni strumenti di analisi statica troveranno anche alcuni potenziali punti morti.

Oltre a ciò aiuta a ottenere l'architettura direttamente per imporre l'ordine di acquisizione delle risorse. Ad esempio, la stratificazione aiuta ad assicurarsi che i blocchi di livello superiore siano presi prima di quelli inferiori, ma attenzione ai callback.