Wie debuggen Sie einen Deadlock?

Question

Ansonsten weiß ich nicht, ob ich es jetzt reproduzieren kann, dass es passiert ist (ich habe diese spezielle Anwendung für ein oder zwei Wochen jetzt ohne Problem verwendet), vorausgesetzt, dass ich meine Anwendung im VS-Debugger ausführe , wie sollte ich über das Debuggen eines Deadlocks gehen, nachdem es passiert ist? Ich dachte, ich könnte Callstacks erreichen, wenn ich das Programm pausiere und dann sehen würde, wo die verschiedenen Threads waren, als es passierte, aber das Klicken auf Pause brachte Visual Studio in einen Deadlock, bis ich meine Anwendung beendete.

Gibt es eine andere Möglichkeit, als in meinem Quellbaum nach möglichen Problemen zu suchen? Gibt es eine Möglichkeit, die Call-Stacks zu erreichen, sobald das Problem aufgetreten ist, um zu sehen, wo das Problem liegt? Irgendwelche anderen Werkzeuge/Tipps/Tricks, die helfen könnten?

Answer 1

Was Sie getan haben, war der richtige Weg. Wenn Visual Studio ebenfalls blockiert, passiert das hin und wieder. Es ist nur Pech, es sei denn, es gibt ein anderes Problem.

Sie müssen die Anwendung nicht im Debugger ausführen, um sie zu debuggen. Führen Sie die Anwendung normal aus, und wenn der Deadlock auftritt, können Sie VS später anhängen. Strg + Alt + P, wählen Sie den Prozess, wählen Sie den Debugger-Typ und klicken Sie auf attach. Die Verwendung eines anderen Satzes von Debugger-Typen kann das Risiko eines VS-Absturzes reduzieren (besonders, wenn Sie nativen Code nicht debuggen)

Ein Deadlock beinhaltet 2 oder mehr Threads.Sie kennen wahrscheinlich den ersten (wahrscheinlich Ihren UI-Thread), da Sie den Deadlock in Ihrer Anwendung bemerkt haben. Jetzt müssen Sie nur noch den anderen finden. Mit der Kenntnis der Architektur, sollte es einfach sein zu finden (zB was andere Threads die gleichen Schlösser verwenden, die Interaktion mit der Benutzeroberfläche usw.)

Wenn VS nicht bei allen funktioniert, können Sie immer windbg verwenden . Download hier: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Answer 2

Sie können verschiedene Programme wie Intel (R) Parallel Inspector verwenden:
http://software.intel.com/en-us/intel-parallel-inspector/

Solche Programme, die Sie Orte in Ihrem Code mit potentiellen Deadlocks zeigen kann. Allerdings sollte man dafür bezahlen, oder nur Evaluierungszeitraum verwenden. Ich weiß nicht, ob es irgendwelche kostenlosen Tools wie diese gibt.

Answer 3

Ich würde versuchen, verschiedene Ansätze in der folgenden Reihenfolge:

-First, den Code prüfen für Thread-Sicherheit Verletzungen suchen, um sicherzustellen, dass Ihre kritischen Regionen nicht versuchen, andere Funktionen aufrufen, die wiederum um eine kritische Region zu sperren.

- Verwenden Sie ein beliebiges Werkzeug, mit dem Sie Thread-Aktivitäten visualisieren können. Ich verwende ein internes Perl-Skript, das ein von uns erstelltes Betriebssystemprotokoll analysiert und alle Kontextwechsel grafisch darstellt und anzeigt, wenn ein Thread vorweggenommen wird.

-Wenn Sie kein gutes Tool finden können, führen Sie eine Protokollierung durch, um die letzten Threads anzuzeigen, die vor dem Deadlock ausgeführt wurden. Dies gibt Ihnen einen Hinweis darauf, wo das Problem entstehen könnte. Es hilft, wenn die Sperrmechanismen eindeutige Namen haben, wie wenn ein Objekt einen eigenen Thread hat, einen eigenen Semaphor oder Mutex erstellen, nur um diesen Thread zu verwalten.

Ich hoffe, das hilft. Viel Glück!

Answer 4

Genau wie überall gibt es keine "Silver Bullet" -Werkzeuge, um alle Deadlocks zu erfassen. Es dreht sich alles um die Reihenfolge, in der verschiedene Threads Ressourcen erwerben, so dass Sie herausfinden müssen, wo der Auftrag verletzt wurde. Normalerweise liefert Visual Studio oder ein anderer Debugger Stack-Traces und Sie können herausfinden, wo die Diskrepanz liegt. DevPartner Studio bietet Deadlock-Analyse, aber das letzte Mal, als ich überprüft habe, gab es zu viele falsche Positive. Einige statische Analyse-Tools werden auch einige potentielle Deadlocks finden.

Darüber hinaus hilft es, die Architektur direkt zum Erzwingen der Ressourcenerfassungsreihenfolge zu bekommen. Zum Beispiel hilft das Layern, sicherzustellen, dass Sperren auf der oberen Ebene vor den niedrigeren Sperren genommen werden, aber hüten Sie sich vor Rückrufen.