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

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