AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Sonstige Fragen zu Delphi Delphi Ursache für hängende Applikation herausfinden
Thema durchsuchen
Ansicht
Themen-Optionen

Ursache für hängende Applikation herausfinden

Ein Thema von Bodenseematze · begonnen am 29. Jan 2024 · letzter Beitrag vom 27. Feb 2024
Antwort Antwort
Bodenseematze

Registriert seit: 10. Jul 2023
68 Beiträge
 
#1

Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 10:32
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...

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...
  Mit Zitat antworten Zitat
Benutzerbild von blawen
blawen

Registriert seit: 1. Dez 2003
Ort: Luterbach (CH)
675 Beiträge
 
Delphi 12 Athens
 
#2

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 10:43
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.
Roland
  Mit Zitat antworten Zitat
Bodenseematze

Registriert seit: 10. Jul 2023
68 Beiträge
 
#3

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 11:18
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.

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


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"?
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.490 Beiträge
 
Delphi 7 Professional
 
#4

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 11:46
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
  Mit Zitat antworten Zitat
Bodenseematze

Registriert seit: 10. Jul 2023
68 Beiträge
 
#5

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 15:03
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... )
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.490 Beiträge
 
Delphi 7 Professional
 
#6

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 15:27
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.
  Mit Zitat antworten Zitat
Bodenseematze

Registriert seit: 10. Jul 2023
68 Beiträge
 
#7

AW: Ursache für hängende Applikation herausfinden

  Alt 29. Jan 2024, 16:38
Hallo,
bei MadExcept auch "check for frozen main thread" eingestellt?
Ich habe jetzt mal MadExcept mit Option "check for frozen main thread" mitlaufen lassen.


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, ...).


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...
  Mit Zitat antworten Zitat
Antwort Antwort

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:36 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz