[Behoben, siehe Beitrag #13] Close; im TTimer lässt Programm manchmal abschmieren

[a.def]

Nach fast getaner Arbeit startet mein Programm einen TTimer.
Der TTimer prüft, ob die Hauptarbeit denn nun wirklich vorbei ist oder nicht anhand dreier Boolean-Variablen die an verschiedenen Stellen gesetzt werden / resettet werden.

Trifft alles zu, steht im Timer Close;

In manchen Fällen schmiert hier das Programm ab. Ich schreibe zum Test vor dem Close im Close-Event selber an oberster Stelle eine Log-Datei. Etwa so

Delphi-Quellcode:

// Programm wird gestartet
// Wenn Programm gestartet, dann wird eine Prozedur aufgerufen, welche einen Timer (Timer_Arbeit) startet
// Dieser Timer setzt Timer_Arbeit.Enabled:=False und klickt Button1

// Wenn Button1-Arbeit fertig, wird Timer1 gestartet
// Sobald ArbeitImGange=True, darf Timer1 Close; aufrufen.

// Der Fehler kommt oft zwischen dem Ende von Timer_Arbeit und Timer1

procedure TForm1.Button1Click(Sender: TObject);
begin
 ArbeitImGange := True;
 // mache deine Arbeit!

 // wenn fertig dann...
 Timer1.Enabled := True;

 ArbeitImGange := False;
end;

// timer
procedure Timer1Timer(Sender: TObject);
begin
 if not ArbeitImGange dann
  begin
   Timer1.Enabled := False;
   schreibeLog('1. Schließen gestartet');
   Close;
  end;
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
 schreibeLog('2. Schließen geht weiter ...');
 // mach weiter
end;

Wenn das Programm abschmiert, steht Lognachricht #1 im Log, #2 aber nicht.
Wenn ich in der Windows-Meldung (APPCRASH) "Das Programm funktioniert nicht mehr" auf OK klicke, wird auch #2 ins Log geschrieben.

D.h da schmiert zwar irgendetwas ab, sobald ich die Windows-Meldung aber bestätige geht es weiter.

Darf man Close; nicht in einem Timer verwenden?

[stahli]

Grundsätzlich sollte das kein Problem machen.

Tust Du im Timer-Event evtl. noch mehr, was Du hier bisher verschwiegen hast? :stupid:
Oder gibt der Debugger vielleicht irgend welche näheren Hinweise auf die Problemursache?

[taveuni]

Zitat:

Zitat von a.def (Beitrag 1354612)

Wenn ich in der Windows-Meldung (APPCRASH) "Das Programm funktioniert nicht mehr" auf OK klicke, wird auch #2 ins Log geschrieben.

Und was steht dann in der Windows Ereignisanzeige?

[a.def]

Ich stoppe den Timer, gebe drei Bool'sche Variablen einen Wert, schreibe den Test-Log und rufe Close; auf.

Und dann schmiert es ab und zu ab.
In diesem Fall kann ich den Debugger leider nicht verwenden, da das Programm über ein CMD-Fenster mit Parametern aufgerufen wird.

Zitat:

Und was steht dann in der Windows Ereignisanzeige?

Suche ich gleich mal raus wenn der Fehler erneut auftritt.

In der Problemsignatur steht nur Unsinn und

Zitat:

Ausnahmecode: c0000005

Jetzt kam der Fehler zum Glück direkt beim ersten Mal.
Timer1 wird aus einer Prozedur eingeschaltet, welche ebenfalls vorher über einen Timer aufgerufen wurde.
Ab und zu kommt der Fehler auch am Ende des Haupttimers und Timer1.

[DeddyH]

Zitat:

Zitat von a.def (Beitrag 1354616)

In diesem Fall kann ich den Debugger leider nicht verwenden, da das Programm über ein CMD-Fenster mit Parametern aufgerufen wird.

Dann gib doch diese Parameter in Delphi über "Start - Parameter" im Feld "Parameter" ein, dann geht auch das Debuggen (oder gibt es das in der Starter nicht?).

[a.def]

Zitat:

Zitat von DeddyH (Beitrag 1354617)

(oder gibt es das in der Starter nicht?).

Ups da habe ich mich verklickt. Ich habe damals die Professional gekauft als sie runtergesetzt war (auch wenn ich kein Professional bin :stupid: )

Funktioniert einwandfrei. Nur was mache ich dann danach, wenn eine Exception geworden wurde?
Weil Chinesisch lesen ist schwierig.

[Aviator]

Zitat:

Zitat von DeddyH (Beitrag 1354617)

Zitat:

Zitat von a.def (Beitrag 1354616)

In diesem Fall kann ich den Debugger leider nicht verwenden, da das Programm über ein CMD-Fenster mit Parametern aufgerufen wird.

Dann gib doch diese Parameter in Delphi über "Start - Parameter" im Feld "Parameter" ein, dann geht auch das Debuggen (oder gibt es das in der Starter nicht?).

Die Lösung wollte ich auch gerade vorschlagen. Alternativ kann er ja einfach so machen als ob die Parameter übergeben wurden.

[EmWieMichael]

Probier doch mal, hinter schreibeLog(1,...) ein Application.ProcessMessages einzufügen.

[a.def]

Werde ich sofort machen und dann gucken was passiert.
Das kann leider von Mal zu Mal etwas dauern bis ich ein Ergebnis habe, da der Fehler recht selten auftaucht.

Ein Application.ProcessMessages; im Timer bringt leider keine Änderung.

Im Debugger steht aktuell immer

Zitat:

00449E2B 3B7308 cmp esi,[ebx+$08]

Manchmal steht der grüne Pfeil auch an "Leave".

Ich habe das Application.ProcessMessages; jetzt mal in den Timer direkt nach begin gesetzt. Mal sehen, ob es etwas ändert.
Ok tut es nicht.

[himitsu]

Im Debugger starten und schauen wo man landet, wenn die exception geworfen wird.
* siehe Cursorposition/Markierung im Quellcode
* siehe Stacktrace

Und vielleicht vorher einen Haltepunkt auf Close und dann mit F7/F8 weitergucken.

[a.def]

Der Fehler kommt jetzt wieder seltener :roll:

Aber er kommt soweit ich das jetzt erst einmal erkennen konnte nur wenn ich Timer1 aktiviere, welche das Programm schließt.

Vom Close kommt der Fehler wohl auch nicht sondern es passiert genau zwischen Ende Timer_Arbeit und If-Eintrittspunkt Timer1 :evil:

[Der schöne Günther]

Du hast mit dem Debugger ein mächtiges Werkzeug. Nutze es.

[a.def]

-Warum ist der Post nach dem Bearbeiten hier plötzlich doppelt?-

Zitat:

* siehe Cursorposition/Markierung im Quellcode
* siehe Stacktrace

Die Cursorposition im Code wird beim Werfen einer Exception nicht verändert.

Der Fehler tritt wohl hier auf. Er tritt manchmal auf aber nicht immer:
- Classes.pas

Delphi-Quellcode:

procedure TList.Delete(Index: Integer);
var
  Temp: Pointer;
begin
  if (Index < 0) or (Index >= FCount) then // <==
// ...

Ich werde mal meine Listen überprüfen.

Beim Beenden der Anwendung gibt es aber keine Speicherlecks.


-------------


Ich glaube den Fehler jetzt mit dem Debugger gefunden zu haben.
Ich werde jetzt für etwa eine Stunde Tests durchführen und dann Feierabend machen.
Ich melde mich dann hier im selben Beitrag zurück.


-------------


112 automatisierte Tests am Stück später. Ich denke ich kann sagen, dass der Fehler behoben ist.
Es war nicht das Close-Event und auch kein Timer. Hier wurde ich vom System auf die falsche Spur geschickt.

Es war einfach nur eine TList, aus welcher doppelt Items gelöscht wurden.
Dass das aber in einem APPCRASH resultiert und nicht in einer normalen Exception, war ein bisschen seltsam.

[Luckie]

Zitat:

Zitat von a.def (Beitrag 1354632)

Es war einfach nur eine TList, aus welcher doppelt Items gelöscht wurden.
Dass das aber in einem APPCRASH resultiert und nicht in einer normalen Exception, war ein bisschen seltsam.

Wie sieht denn deine Fehlerbehandlung an dieser Stelle aus? Wenndu da keine Fehlerbehandlung hast, dann wir die Exception bis ans Betriebssystem hoch gereicht, was letztendlich den Absturz der Anwendung bedeutet.

[a.def]

Zitat:

Zitat von Luckie (Beitrag 1354644)

Zitat:

Zitat von a.def (Beitrag 1354632)

Es war einfach nur eine TList, aus welcher doppelt Items gelöscht wurden.
Dass das aber in einem APPCRASH resultiert und nicht in einer normalen Exception, war ein bisschen seltsam.

Wie sieht denn deine Fehlerbehandlung an dieser Stelle aus? Wenndu da keine Fehlerbehandlung hast, dann wir die Exception bis ans Betriebssystem hoch gereicht, was letztendlich den Absturz der Anwendung bedeutet.

Fehlerbehandlung habe ich da gerade keine, wird aber selbstverständlich nachgebessert!

Aktuell frage ich nur ab, ob die Liste ungleich nil ist und dann werden alle Einträge von Count-1 bis 0 gelöscht.

Ich denke ein Assigned() sollte hier reichen. Oder ich überdenke mal diese Prozedur und baue sie so, dass sie nur einmalig aufgerufen wird. Ist ja auch Blödsinn zwei Aufrufe.

[Luckie]

Zitat:

Zitat von a.def (Beitrag 1354645)

Zitat:

Zitat von Luckie (Beitrag 1354644)

Zitat:

Zitat von a.def (Beitrag 1354632)

Es war einfach nur eine TList, aus welcher doppelt Items gelöscht wurden.
Dass das aber in einem APPCRASH resultiert und nicht in einer normalen Exception, war ein bisschen seltsam.

Wie sieht denn deine Fehlerbehandlung an dieser Stelle aus? Wenndu da keine Fehlerbehandlung hast, dann wir die Exception bis ans Betriebssystem hoch gereicht, was letztendlich den Absturz der Anwendung bedeutet.

Fehlerbehandlung habe ich da gerade keine, wird aber selbstverständlich nachgebessert!

Dann ist es ja klar, dass bei einer Exception die Anwendung abstürzt.

Und warum "mache ich dann mal später"? Hättest du s gleich richtig gemacht hättest du dir zwei Tage Fehlersuche erspart.

[a.def]

Zitat:

Und warum "mache ich dann mal später"? Hättest du s gleich richtig gemacht hättest du dir zwei Tage Fehlersuche erspart.

Aus Fehlern lernt man für später :thumb: