Ursache für hängende Applikation herausfinden

[Bodenseematze]

Hallo,

ich habe aktuell ein sehr seltsames Problem.
Eine meiner Applikationen bleibt immer an einer von zwei Stellen hängen und lässt sich nur durch abschießen beenden.
Die eine Stelle soll eine Datei von einem Verzeichnis in ein anderes kopieren.
Das Zielverzeichnis ist ein kurz vorher erzeugtes Unterverzeichnis im Temp-Verzeichnis.

Hier bleibt immer der eigentliche "Kopieraufruf" hängen - dabei ist es egal, ob ich eine Implementierung von CopyFileW, IFileOperation oder ShFileOperation verwende... :roll:

Und der ähnlich gelagerte Aufruf (Kopieren einer Datei aus dem selbem Quellverzeichnis in ein generiertes Temp-Verzeichnis) klappt in einer anderen Applikation völlig problemlos.

Die zweite Stelle, an der es immer wieder mal hängen bleibt, ist eine Datenbankabfrage.
Auch diese ist sowohl im selben als auch in anderen Programmen in gleicherweise verwendet und funktioniert dort problemlos (zu 80% auch in besagtem Programm - nur eben manchmal nicht...)

Ich bin mir also ziemlich sicher, dass das eigentliche Problem nicht an den Aufrufen liegt, bei denen das Programm hängen bleibt, sondern vermutlich irgendwo ganz anders und sich nur so auswirkt.
Ich habe aber keine Ahnung, wie ich dem Problem auf die Spur kommen soll...

Das ganze mit Delphi 7 Enterprise, Betriebssyteme (VMs) von Win7 - Win10 wurden ausprobiert; überall das selbe Verhalten.
FastMM4, MadExcept etc. sind auch integriert - melden aber (bis zum Hänger) auch nichts...

Richtig debuggen kann ich schon lange (mehrere Jahre) nicht mehr - die Delphi IDE bleibt bei mir hängen, wenn ich versuche eine Applikation im Debugger zu starten - auch, wenn ich es über Remote-Debugging auf dem gleichen Rechner versuche (das funktioniert manchmal noch, aber meistens bleibt es auch hängen, wenn ich mich auf den laufenden Prozess setze).
Mein "debuggen" passiert also ausschließlich über Log-Ausgaben - und hier kann ich eben noch "vor" dem Datei-Kopieraufruf loggen und die Ausgabe direkt danach kommt nichts mehr... :(

[blawen]

Meine Glaskugel ist aktuell in der Reparatur, insofern kann ich nur im Nebel stochern ;-)

Ohne etwas Code ist es schwierig Tipps zu geben.
Im Falle "Datei kopieren" tippe ich darauf, dass die Pfadangabe fehlerhaft ist - sehr oft dürfte der Fehler bei falsch gesetzten "\" liegen.
Daher würde ich den Pfadstring ausgeben lassen und vergleichen.

Bei der Datenbankabfrage dürfte es ev. darauf hinauslaufen, dass entweder der Server nicht immer erreichbar ist oder dass die SQL-Abfrage (?) Fehlerbehaftet ist.
(z.B. Timeout-Fehler, weil die Abfrage zu lange dauert)

Wie geschrieben, ohne Code bleibts beim Spekulieren.

[Bodenseematze]

Zitat:

Zitat von blawen (Beitrag 1532698)

Ohne etwas Code ist es schwierig Tipps zu geben.

das ist mir schon klar, der Quellcode der "Hänger"-Stelle dürfte hier aber nichts bringen, da es wie gesagt, auch bei unterschiedlichen Kopier-Varianten zu dem Hänger kommt (und bei einem anderen Programm, das einem ähnlichen Ablauf folgt, nicht passiert).

Ich habe auch schon ein Testprogramm geschrieben, das nur diesen Aufruf simuliert und ihm die exakt gleichen Pfade gegeben.
Da funktioniert es ohne Probleme.

Zitat:

Zitat von blawen (Beitrag 1532698)

Im Falle "Datei kopieren" tippe ich darauf, dass die Pfadangabe fehlerhaft ist - sehr oft dürfte der Fehler bei falsch gesetzten "\" liegen.

Wenn es daran liegen würde, müsste der Aufruf doch mit einem Fehler / Exception zurück kommen...

Im aktuell verwendeten Code wird ein IFileOperation-CopyItem Aufruf durchgeführt, als Quellpfad ist der absolute Pfad zu einer Datei angegeben (

Code:

C:\Entw\Reports\MyReport.rpt

) als Ziel ein Verzeichnis (

Code:

C:\Temp\VoH33732038\

).
Es wurde auch geprüft, dass die Quelldatei und das Zielverzeichnis existieren (und es sich im Falle des Ziels auch um ein Verzeichnis handelt).
Teswtweise ist als einziges Flag "FOF_NOCOPYSECURITYATTRIBS" angegeben.
Wie gesagt, der gleiche Aufruf in einem Testprogramm funktioniert einwandfrei...

Zitat:

Zitat von blawen (Beitrag 1532698)

Bei der Datenbankabfrage dürfte es ev. darauf hinauslaufen, dass entweder der Server nicht immer erreichbar ist oder dass die SQL-Abfrage (?) Fehlerbehaftet ist.
(z.B. Timeout-Fehler, weil die Abfrage zu lange dauert)

Wie geschrieben, ohne Code bleibts beim Spekulieren.

Da es mit den gleichen SQL-Aufrufen meistens funktioniert, bin ich mir (zimelich) sicher, dass hier kein Fehler vorliegt / vorliegen kann...

Ich habe irgendwie das Gefühl, dass es sich um irgendwelche Speicherüberschreiber handelt, die an einer ganz anderen Stelle passieren...
Wenn ich das Programm ausserhalb der IDE starte und zu dem Hänger "bringe" und mich dann über die IDE auf das laufende Programm setze ("Attach to process") und dann versuche, im angehaltenen Prozess auf das Debug-Fenster "Event Log" zu schalten, steht dort folgendes:

Code:

ODS:    *** A stack buffer overrun occurred in .\MyProc  /LOG=Full AU 95211 01:   Process MyProc.exe (16344)
ODS: This is usually the result of a memory copy to a local buffer or structure where the size is not properly calculated/checked.  Process MyProc.exe (16344)
ODS: If this bug ends up in the shipping product, it could be a severe security hole.  Process MyProc.exe (16344)
ODS: The stack trace should show the guilty function (the function directly above __report_gsfailure).  Process MyProc.exe (16344)
ODS:  *** enter .exr 77453DC8 for the exception record  Process MyProc.exe (16344)
ODS:  *** then kb to get the faulting stack   Process MyProc.exe (16344)

Das deutet doch auf Stack-Probleme / -Überschreiber hin, oder?
Aber was soll mir diese 'Hilfe' in dem Fenster jetzt sagen? Ich habe keine "Stack Trace - Datei" (die ich unterr "Stack Traces" laden könnte) und wo soll ich ".exc 777453DC8" eingeben? Und wo "kb"?

[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:

Zitat von Delphi.Narium (Beitrag 1532701)

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... :roll:)

[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:

Zitat von hoika (Beitrag 1532712)

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

Zitat:

Zitat von Bodenseematze (Beitrag 1532708)

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

:lol:

Zitat:

Zitat von Delphi.Narium (Beitrag 1532711)

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:

Zitat von Delphi.Narium (Beitrag 1532711)

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 :wink:.
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