Ursache für hängende Applikation herausfinden

[Delphi.Narium]

Hast Du mit ausführlicher MAP-Datei kompiliert? Eventuell findest Du dort eine Adresse, die dem angegebenen Wert "ähnlich" ist, dann könnte der Fehler in der Nähe des dort angebenen Bereiches zu finden sein.

Bekommst Du z. B. als Fehleradresse 002D22B4, dann könntest Du in der MAP-Datei die Zeilennummer im Quelltext finden, die das Problem verursacht.

Code:

Line numbers for Unit1(..\Unit1.pas) segment .text

   608 0001:002D22B4   608 0001:002D22BB

D. h.: In dem Beispiel wäre eventuell bei Zeile 600 in der Unit1 eine Fehlerursache zu finden.

Schau bitte einfach mal in der MAP-Datei nach, ob Du die Zeichenfolge :77453DC8 findest. Wenn nicht, versuche es mit :77453DC ..., bis Du was findest oder eben auch nicht.

Ab und an komme ich mit dieser "Suchmethode" schonmal weiter, manchmal jedoch auch nicht und es kann sehr mühsam werden

Ob das jetzt ein professionelles Vorgehen ist, weiß ich nicht, aber wenn es hilft

[Bodenseematze]

Zitat von Delphi.Narium:

Hast Du mit ausführlicher MAP-Datei kompiliert? Eventuell findest Du dort eine Adresse, die dem angegebenen Wert "ähnlich" ist, dann könnte der Fehler in der Nähe des dort angebenen Bereiches zu finden sein.

Nein, leider nicht - die Adressen in der MAP-Datei sind alle wesentlich niedriger (eher so, wie Dein Beispiel...)

Ich habe jetzt mal MadExcept mit Option "check for frozen main thread" mitlaufen lassen.
Nachdem dieser den Hänger feststellt, zeigt er mir folgenden Stack an:

Code:

7736FF74  +0044  ntdll.dll           RtlEnterCriticalSection
4002FE37  +0007  rtl70.bpl  Classes   ThreadList.LockList
01984929  +015D  vcl70.bpl  Controls  TWinControl.PaintControls
773A508B  +004B  ntdll.dll              KiUserCallbackDispatcher
753A101A  +000A  win32u.dll             NtUserPeekMessage
769FBB99  +0169  user32.dll         PeekMessageW
75D4A0EE  +003E shcore.dll            # 161
75D49E73  +0013 shcore.dll           ShCreateThread

und davor kommt meine letzte Code-Zeile, in der erfolgt der Wrapper-Aufruf von IFIleOperation.PerformOperations

Es sieht hier doch so aus, als ob er auf die Freigabe / den Zugriff auf eine gesperrte Ressource wartet?!

Wenn ich das ganze statt mit meine IFileOperation-Implementierung mit "CopyFileW" mache, sieht der MadExcept Call-Stack bei der Freeze-Erkennung folgendermaßen aus:

Code:

7736FF74  +0044  ntdll.dll           RtlEnterCriticalSection
4002FE37  +0007  rtl70.bpl  Classes   ThreadList.LockList
01984929  +015D  vcl70.bpl  Controls  TWinControl.PaintControls
773A508B  +004B  ntdll.dll              KiUserCallbackDispatcher
769FBB99  +0169  user32.dll         PeekMessageW
75286B21  +9E1  RPCRT4.dll              NdrClientCall2
761A6C3A  +000 combase.dll              ObjectSublessClient32
76139579  +0B9  combase.dll              CoCreateInstance
3788EF44  +2F4  CRPE32.dll              PEOpenEngineEx
378941A5  +0B5  CRPE32.dll              PEOpenEngine

die weiteren Aufrufe sind in meinem Code bzw. im "Crystal Reports"-Wrapper beim Setzen von Reportdaten... (also nicht beim Kopieren!)
Auch hier wieder das Warten auf den Zugriff auf eine Ressource...
(das kann aber natürlich auch einfach ein anderer und nicht der eigentliche Problemthread sein... )

[Delphi.Narium]

Du schreibst u. a. von Datenbank, Freigaben, Resourcen, ...

Kann es sein, dass es da "irgendwo" ein bisher nicht näher spezifiziertes Netzwerkproblem gibt, welches sich durch ein unliebsames Aufhängen des Programmes auf sich aufmerksam macht?
Dies könnte eventuell auch eine Erklärung dafür sein, dass identischer Code andernorts keine Probleme bereitet, andererseits aber vollständig unterschiedliche Implementierungen der gleichen Aufgabe zu einem identischen Problem führen.

Versuch' bitte mal herauszufinden, ob das Problem nicht eventuell von außerhalb auf Dein Programm einwirkt.

[hoika]

Hallo,
bei MadExcept auch "check for frozen main thread" eingestellt?

[Bodenseematze]

Zitat von hoika:

Hallo,
bei MadExcept auch "check for frozen main thread" eingestellt?

Zitat von Bodenseematze:

Ich habe jetzt mal MadExcept mit Option "check for frozen main thread" mitlaufen lassen.

Zitat von Delphi.Narium:

Du schreibst u. a. von Datenbank, Freigaben, Resourcen, ...

Der Datenbankserver ist ein MS SQL-Server, der auf einem anderen Rechner läuft.
Beim Rest habe ich Zugriff auf Ressourcen (also z.B. Dateien / Verzeichnisse / Semaphoren etc.) auf dem lokalen Rechner gemeint.
Und mit Freigaben eben die üblichen Sperr-/und Freigabe-Mechanismen von Windows für diese Ressourcen (Mutex, Semaphoren, Critical Section, ...).

Zitat von Delphi.Narium:

Dies könnte eventuell auch eine Erklärung dafür sein, dass identischer Code andernorts keine Probleme bereitet, andererseits aber vollständig unterschiedliche Implementierungen der gleichen Aufgabe zu einem identischen Problem führen.

Es ist nicht andernorts, es ist auf dem selben Rechner - nur ein anderes Delphi-Programm .
Und bzgl. der unterschiedlichen Implementierungen: die Auswirkung des Problems sind die gleichen (das Programm "hängt") - aber zumindest das interne Verhalten ist doch etwas unterschiedlich.
Im CopyFileW-Fall wird wohl noch die Kopie der Datei angelegt (hier kommt noch die Log-Ausgabe nach dem Aufruf) und erst danach hängt das Programm in einem "WaitForCriticalSection"-Aufruf.
Im IFileOperation-Fall hängt es direkt im API-Aufruf (wobei es dort auch so aussieht, als ob da intern der WaitForCriticalSection-Aufruf gemacht wird).
Ich sehe nur nicht, auf _was_ da gewartet wird bzw. mit welchem System-Objekt die CriticalSection verknüpft ist...

[Delphi.Narium]

Das sieht dann wirklich so aus, als würde sich in genau diesem Programm irgendwas "verstubbeln". Wenn alles in allen Programmen gleich ist, vom Quelltext (der betroffenen Routine(n)), über den Rechner bis zur Datenbank über die Freigaben und alle weiteren Resourcen, da müsste man dann wohl mal in die Source schauen können, um Hilfestellung geben zu können.

[TigerLilly]

Wie lange "hängt" das Programm dann? Kommt irgendwann eine Meldung oder tut sich irgendwann etwas?

Scheinbares "ewiges" Hängen könnte sein:
- Endlosschleife irgendwo
- Dialog oder Fenster im Hintergrund oder außerhalb des Bildschirms

Was auch wie "hängen" aussieht:
- warten auf ein timeout (MSSQL Server und Locks!)
- rekursion ohne ende

[jaenicke]

Das sollte klar sein, aber zur Sicherheit frage ich einfach mal. Du greifst im Thread nicht auf irgendwelche VCL-Komponenten zu, oder?

Und interessant wäre der komplette MadExcept Bericht, denn wenn da ein Deadlock im Spiel ist, braucht man die Stacktraces aller Threads. Du kannst den ja zensieren oder nur privat schicken.

[Bodenseematze]

Zitat von Delphi.Narium:

Das sieht dann wirklich so aus, als würde sich in genau diesem Programm irgendwas "verstubbeln".

Ja

Zitat von Delphi.Narium:

Wenn alles in allen Programmen gleich ist, vom Quelltext (der betroffenen Routine(n)), über den Rechner bis zur Datenbank über die Freigaben und alle weiteren Resourcen, da müsste man dann wohl mal in die Source schauen können, um Hilfestellung geben zu können.

Der Quelltext ist derselbe, die Datenbank ist die selbe und der pronzipielle Ablauf für den Fehlerfall sind gleich - die Programme kopieren allerdings unterschiedliche Dateien (aus dem selben lokalen Quellverzeichnis in ein jeweils selber generiertes temp. lokales Verzeichnis)...

Mit den Quellen ist das so eine Sache - mal abgesehen davon, dass die Quellen wohl etwas zu viel wären, darf ich diese nicht so ohne weiteres (komplett) rausgeben.
Und nur Teile bringt vermutlich nicht allzu viel...

Zitat von TigerLilly:

Wie lange "hängt" das Programm dann? Kommt irgendwann eine Meldung oder tut sich irgendwann etwas?

Wenn ich Freeze-Erkennung in MadExcept nicht einschalte, hängt das Programm "ewig".

Zitat von TigerLilly:

- Endlosschleife irgendwo

Ich denke, das hätte ich über MadExcept gesehen...

Zitat von TigerLilly:

- Dialog oder Fenster im Hintergrund oder außerhalb des Bildschirms

Um solche Dinge auszuschließen habe ich extra beim Kopieren die Flags (NoConfirm, NoGui, etc.) entfernt - aber ausschließen kann ich das natürlich nicht.

Zitat von TigerLilly:

- warten auf ein timeout (MSSQL Server und Locks!)

Das will ich natürlich nicht ausschließen, habe aber bereits auf dem SQL-Server mal mitgetraced und nichts auffälliges gefunden.

Zitat von TigerLilly:

- rekursion ohne ende

Auch das müsste ich eigentlich bei der MadExcept "Freeze-Erkennung" gesehen haben....

Zitat von jaenicke:

Das sollte klar sein, aber zur Sicherheit frage ich einfach mal. Du greifst im Thread nicht auf irgendwelche VCL-Komponenten zu, oder?

Nicht, dass ich wüßte

Zitat von jaenicke:

Und interessant wäre der komplette MadExcept Bericht, denn wenn da ein Deadlock im Spiel ist, braucht man die Stacktraces aller Threads. Du kannst den ja zensieren oder nur privat schicken.

Ich schicke ihn Dir mal per privater Mail...

[himitsu]

Mit Debugger starten, oder beim Hängen den Debugger anhängen,
auf "Pause" gedrückt (falls nicht automatisch geschehen)
und dann im Stacktrace des MainThreads nachsehn.