Ursache für hängende Applikation herausfinden

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

[Bodenseematze]

Zitat von himitsu:

Mit Debugger starten, oder beim Hängen den Debugger anhängen

Würde ich gerne - aber:

Zitat von Bodenseematze:

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

Das hier...

Zitat von Kas Ob.:

Zitat von Bodenseematze:

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

But you are !

Zitat:

7736FF74 +0044 ntdll.dll RtlEnterCriticalSection
4002FE37 +0007 rtl70.bpl Classes ThreadList.LockList
01984929 +015D vcl70.bpl Controls TWinControl.PaintControls

See, there is no difference if you are accessing the thread itself from VCL or blocking to access something shared with a thread.

...und eine private Message von jaenicke hat mich auf die Spur der Ursache gebracht

Da es viele Aktionen abzuarbeiten gibt und das etwas länger dauert, verwende ich eine Mini-Form soz. als "Bitte Warten..."-Anzeige.
In dieser wird ein Anzeigetext gesetzt (ändert sich mit der aktuellen Aktion) und mit zu und abnehmenden "..." wird signalisiert, dass die Arbeit noch am Laufen ist.
Für dieses Zu- und Abnehmen habe ich eine eigene Klasse TTimerThread verwendet, die einen Thread basierten Timer zur Verfügung stellt bzw. stellen soll.
Eigentlich soll diese Klasse auch die Synchronisierung mit der VCL übernehmen - aber da scheint was nicht richtig zu sein.

Was da genau schief läuft, habe ich noch nicht herausgefunden - vielleicht findet jemand von Euch den Fehler im Code?

Das hier ist die Deklaration:

Delphi-Quellcode:

type
TTimerThread         = class( TThread )
public
   constructor Create(              bSuspend_            : Boolean = false ); virtual;
   destructor  Destroy(); override;

   procedure   Start();
   procedure   Terminate();

   procedure   SetTimerFunc(        evTimerFunc_         : TNotifyEvent );


protected
   procedure   Execute(); override;


private
   _evFlagCancel                                         : TSimpleEvent;
   _evFlagEnabled                                        : TSimpleEvent;
   _evTimerFunc                                          : TNotifyEvent;
   _ui32IntervalInMs                                     : UInt32;
   _bCallFuncOnMainThread                                : Boolean;

   procedure   SetEnabled(          bDoEnable_           : Boolean );
   function    GetEnabled()                              : Boolean;

   procedure   SetInterval(         ui32IntervalInMs_    : UInt32 );

   procedure   SwapToMainThread();


// Properties
public
   property    Enabled                                   : Boolean
                                    read     GetEnabled
                                    write    SetEnabled;

   property    Interval                                  : UInt32
                                    read     _ui32IntervalInMs
                                    write    SetInterval;

   // soll die OnTimer-Methode auf dem Main-Thread ausgeführt werden?
   property    CallOnTimerOnMainThread                   : Boolean
                                    read     _bCallFuncOnMainThread
                                    write    _bCallFuncOnMainThread;

   // Anmerkung: OnTimer wird im Thread ausgeführt...
   property    OnTimer                                   : TNotifyEvent
                                    read     _evTimerFunc
                                    write    SetTimerFunc;
end; (* END_CLASS TTimerThread *)

und hier die Implementierung:

Delphi-Quellcode:

constructor TTimerThread.Create(    bSuspend_            : Boolean = false );
begin
   inherited Create( true     {* CreateSuspended *} );

   _bCallFuncOnMainThread  := false;
   _ui32IntervalInMs       := 1000;
   _evTimerFunc            := nil;

   _evFlagEnabled          := TSimpleEvent.Create();
   _evFlagEnabled.ResetEvent();
   _evFlagCancel           := TSimpleEvent.Create();
   _evFlagCancel.ResetEvent();

   FreeOnTerminate         := false;
   Priority                := tpNormal;

   // lass den Thread loslaufen:
   if ( NOT bSuspend_ ) then begin
      Start();
   end;
end; (* END_CONSTRUCTOR TTimerThread.Create *)


destructor  TTimerThread.Destroy();
begin
   Terminate();

   // synchronisieren:
   if ( GetCurrentThreadID = MainThreadID ) then begin
      WaitFor();
   end;

   FreeAndNil( _evFlagCancel );
   FreeAndNil( _evFlagEnabled );

   inherited Destroy();
end; (* END_DESTRUCTOR TTimerThread.Destroy *)


procedure   TTimerThread.Terminate();
begin
   // Aufruf statische Methode TThread.Terminate:
   inherited Terminate();

   _evFlagEnabled.ResetEvent();  // Timer stoppen
   _evFlagCancel.SetEvent();     // Cancel-Flag setzen
end; (* END_PROC TTimerThread.Terminate *)


procedure   TTimerThread.SetTimerFunc(
                                    evTimerFunc_         : TNotifyEvent );
begin
   _evTimerFunc            := evTimerFunc_;
end; (* END_PROC TTimerThread.SetTimerFunc *)


procedure   TTimerThread.SetEnabled(bDoEnable_           : Boolean );
begin
   if ( bDoEnable_ ) then begin
      _evFlagEnabled.SetEvent();
   end
   else begin
      _evFlagEnabled.ResetEvent();
   end;
end; (* END_PROC TTimerThread.SetEnabled *)


function    TTimerThread.GetEnabled()                     : Boolean;
begin
   Result                  := false;
   if ( WaitForSingleObject(
                           _evFlagEnabled.Handle,
                           0) = WAIT_OBJECT_0 ) then begin
      Result               := true;
   end;
end; (* END_FUNC TTimerThread.GetEnabled *)


procedure   TTimerThread.SetInterval(
                                    ui32IntervalInMs_    : UInt32 );
begin
   _ui32IntervalInMs       := ui32IntervalInMs_;
end; (* END_PROC TTimerThread.SetInterval *)


procedure   TTimerThread.Start();
begin
   // startet einen bei Create nicht gestarteten Thread...
   Resume();
end; (* END_PROC TTimerThread.Start *)


procedure   TTimerThread.Execute();
var
   arrWaitHandles    : TWOHandleArray;
   i64WaitInterval   : Int64;
   i64LastProcTime   : Int64;
   i64Freq           : Int64;
   i64Start          : Int64;
   i64Stop           : Int64;
   dwWaitResult      : DWORD;
begin
   QueryPerformanceFrequency( i64Freq );

   arrWaitHandles[ 0 ]     := _evFlagEnabled.Handle;
   arrWaitHandles[ 1 ]     := _evFlagCancel.Handle;
   arrWaitHandles[ 2 ]     := INVALID_HANDLE_VALUE;
   i64LastProcTime         := 0;

   while ( (NOT Terminated) and (NOT Application.Terminated) ) do begin
      dwWaitResult         := MsgWaitForMultipleObjects(
                                 2,                {* nCount *}
                                 arrWaitHandles,   {* var pHandles *}
                                 false,            {* fWaitAll *}
                                 INFINITE,         {* dwMilliseconds *}
                                 QS_ALLINPUT       {* dwWakeMask *} );
      case dwWaitResult of
         WAIT_FAILED: begin   // 0xFFFFFFFF
            // Fehler beim warten
            // --> da hören wir auf (Thread beenden)!
            Break;
         end;

         ( WAIT_OBJECT_0 + 1 ): begin  // 0x00000001
            // Cancel-Event (_evFlagCancel)
            // --> Thread beenden
            Break;
         end;

         ( WAIT_OBJECT_0 + 0 ): begin  // 0x00000000
            // Enable-Event (_evFlagEnabled)
            // --> Timer-Methode aufrufen
            if ( Assigned(_evTimerFunc) ) then begin
               i64WaitInterval      := Int64( _ui32IntervalInMs ) - i64LastProcTime;
               if ( i64WaitInterval < 0 ) then begin
                  i64WaitInterval   := 0;
               end;

               if ( WaitForSingleObject(
                                       _evFlagCancel.Handle,
                                       i64WaitInterval) <> WAIT_TIMEOUT ) then begin
                  // Cancel-Event _evFlagCancel
                  // --> Thread beenden
                  Break;
               end;

               if ( Enabled ) then begin
                  QueryPerformanceCounter( i64Start );
                  if ( Terminated or Application.Terminated ) then begin
                     Break;
                  end;
                  if ( Assigned(_evTimerFunc) ) then begin
                     if ( CallOnTimerOnMainThread ) then begin
                        // Methode indirekt auf dem Main-Thread aufrufen:
                        Synchronize( SwapToMainThread );
                     end
                     else begin
                        // Methode direkt aufrufen:
                        try
                           _evTimerFunc( Self );
                        except
                        end;
                     end;
                  end; // if ( Assigned(_evTimerFunc) ) then
                  QueryPerformanceCounter( i64Stop );
                  i64LastProcTime   := ( 1000 * (i64Stop - i64Start) ) div i64Freq;
               end; // if ( Enabled ) then
            end; // if ( Assigned(_evTimerFunc) ) then
         end; // ( WAIT_OBJECT_0 + 1 ): begin

         else begin // ( WAIT_OBJECT_0 + 2 ) = 0x00000002
            // eine der Eingabe-Events (QS_ALLINPUT)
            // --> Nachrichten abarbeiten und wieder warten...
            Application.ProcessMessages();
         end;
      end; // case dwWaitResult of
   end; // while ( NOT Terminated ) do
end; (* END_PROC TTimerThread.Execute *)


procedure   TTimerThread.SwapToMainThread();
begin
   if ( Assigned(_evTimerFunc) ) then begin
      try
         _evTimerFunc( Self );
      except
      end;
   end; // if ( Assigned(_evTimerFunc) ) then
end; (* END_PROC TTimerThread.SwapToMainThread *)

[jaenicke]

Du rufst Application.ProcessMessages im Threadkontext auf und greifst damit ganz tief in die Messagebehandlung der VCL ein. Das kann nicht klappen.

In einer länger laufenden Methode, die im Hauptthread läuft, wird das verwendet, damit die GUI noch reagiert, indem dort die Paint-, Maus- und Tastaturmessages abgearbeitet werden. (Besser ist natürlich, das zu vermeiden.)

In einem Thread ist das nicht nötig (und auch nicht möglich). Wenn du warten möchtest, rufst du einfach Sleep auf. Da der Thread separat läuft, blockierst du damit auch nicht die GUI. Oder du wartest auf ein Event eine definierte Zeit.

[Bodenseematze]

Hmm, auch wenn ich die Stelle Application.ProcessMessages() im Code mit Sleep(0) oder Windows.Yield() austausche,
bleibt das ganze (wie gewohnt ) hängen...

Daran kann es also nicht (nur) liegen...

[himitsu]

Wenn in Application.ProcessMessages wirklich nur die MessageList direkt verarbeitet würde,
dann wäre es egal, die der Thread vermutlich eh nichts in "seiner" Queue hat (bzw. noch keine Queue erstellt war)

Aber dort gibt es eben auch noch anderen Code, welcher auf globale Objekte/Variablen zugreift, welche halt nicht thread-safe sind.