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

[DeddyH]

Zitat von a.def:

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 von DeddyH:

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

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

[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

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

[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 von a.def:

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.

[Aviator]

Zitat von DeddyH:

Zitat von a.def:

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.