Ich habe einen Fehler, den ich jage (ich denke, es ist ein Deadlock). Wenn ich den Code ausführe, bleibt er hängen, ohne dass der Debugger einen Fehler anzeigt, also versuche ich nach einer Weile, die Pause-Taste (Pause) zu drücken. Der Debugger meldet dann "Der Prozess scheint blockiert zu sein ...". Ich kann dann sehen, dass alle Threads an den Zeilen gehalten werden, die EnterCriticalSection mit Ausnahme von einem sagen, das bereits in einem kritischen Abschnitt ist. Wenn ich mir den Thread ansehe, der sich innerhalb des C.S. mit dem Debugger befindet, sehe ich einen grünen Pfeil, begleitet von einem kleinen blauen Kreis, der auf eine Linie mit GetWindowText ... wie folgt zeigt:
%Vor%Wenn ich die Maus über den grünen Pfeil halte, sehe ich den Text "Dies ist die nächste Anweisung, die ausgeführt wird, wenn dieser Thread von der aktuellen Funktion zurückkehrt". Nun, das hat mich verblüfft, weil ich nicht weiß, ob es bedeutet, dass es in "stuff A" steckt und darauf wartet, zurück zu kommen oder es in GetWindowText stecken bleibt und irgendwie darin steckengeblieben ist. Die Argumente für GetWindowText sehen für mich alle vernünftig aus. Wenn ich auf "steppe in" klicke, bekomme ich die Meldung "Es kann kein Schritt gemacht werden. Der Prozess wurde sanft abgebrochen."
EDIT: stuff A ist in der Tat die Aussage:
%Vor%Ihr Problem besteht darin, dass GetWindowText tatsächlich eine Nachricht an das andere Fenster sendet und darauf wartet, dass es zurückkehrt. Wenn dieses Fenster einem anderen Thread gehört, der auf einen kritischen Abschnitt wartet, wartet GetWindowText auf immer.
Sie stecken in GetWindowText und haben einen Deadlock erstellt.
Normalerweise bedeutet ein grüner Pfeil neben einer Codezeile "das ist die nächste Zeile, die ausgeführt würde, wenn wir nicht irgendwo in einem tieferen Stack-Frame stecken". Wie auch immer, VS macht es unmöglich, basierend auf den bisher zur Verfügung gestellten Informationen sicher zu sagen ...
[BEARBEITEN - natürlich können tiefe Kenntnisse von Win32 eine sehr gute Vermutung liefern - siehe die Antwort von "mos" für eine wahrscheinliche Erklärung, die auf den bekannten Fallstricken der GetWindowText () API basiert]
Wie bereits erwähnt, ist das, was Visual Studio Ihnen zeigt, manchmal irreführend. Um genauer zu sehen, was genau passiert, müssen Sie einige nicht hilfreiche "Funktionen" ausschalten, die VS standardmäßig aktiviert. In Extras - & gt; Optionen - & gt; Debugging - & gt; Allgemein, stellen Sie sicher:
Dies sollte Ihnen erlauben:
1) break on / / über / etc die genaue Anweisung, die den Deadlock verursacht hat
2) Sehen Sie die vollständige Stapelverfolgung bis zu diesem Punkt, unabhängig von Modul (en)
3) Siehe Quellcode, wann immer verfügbar, unter der Annahme, dass Symbol & amp; Quellserver sind korrekt konfiguriert
Wie die vorherigen Antworten andeuten, ist Ihr Code in "Stuff A" stecken geblieben.
Kann ich ein anderes Werkzeug für Ihren Werkzeuggürtel vorschlagen?
Ich finde es normalerweise viel einfacher, native Synchronisationsprobleme mit WinDbg zu debuggen. Starten Sie einfach Ihr Programm in WinDbg, zeigen Sie auf die richtigen Symbole und alle Informationen werden mit den! locks,! cs- und k-Befehlen für Ihre Untersuchung zur Verfügung stehen.
Wenn Sie WinDbg noch nicht kennen, werden Sie feststellen, dass das Internet voll mit Informationen darüber ist. Ich empfehle das erweiterte Windows-Debugging ebenfalls.
Es ist ein bisschen schwierig zu starten, im Vergleich zu den benutzerfreundlichen VS Debugger, aber jede Minute, die Sie in das Lernen investieren, wie Sie es verwenden, werden Sie Stunden des Debuggens weiter unten die Straße sparen.
Angenommen, Ihre Frage lautet "Ist das normal?", dann zeigt der Debugger normalerweise die Anweisung an, nachdem sie in einem kritischen Abschnitt hängen geblieben ist.
Tags und Links c++ multithreading visual-studio-2008 debugging