SystemException Ursache finden

[hoika]

Hallo,
dann benutze halt MadExcept, um den Auslöser zu finden.
Je nach Größe des Projektes sage ich aber trotzdem "Code so lange ausklammern, bis die Exception nicht mehr kommt".

Arbeitest Du mit Interfaces?
Die erzeugen bei falscher Benutzung auch die "lustigsten" Meldungen an Stellen, wo du gar nicht dran warst.
Das meistens durch Speicherüberschreiben.

[himitsu]

Das ist die Stelle, welche geknallt hat.
Der "eigentlich" Fehler wird in diese Zeile selber nicht sein.

Dafür würde sich ein Blick in den Stacktrace anbieten, um zu sehen was zum Aufruf dieser Codestelle führte, und wo der Fehler eher zu vermuten ist. (wo z.B ein NIL oder ein ungültiger Objektzeiger verwendet wurde)



Schlimmer wird es, wenn du irgendwo z.B. einen Buffer-Overflow hast, bei dem fremder Speicher zerstört wird und was dann erst später irgendwo anders "eventuell" knallt, sobald da drauf zugegriffen wird.

[hoika]

Hallo,
stack trace -> genau,

und die oben angeführte Tools zeigen halt bei einer Exception genau diesen Stacktrace an.

[Delphi.Narium]

Zitat:

Zitat von akuk (Beitrag 1462089)

@Delphi.Narium

"Wie bist Du dahinter gekommen, dass dort ein Fehler sein könnte?"

In dem ich die Adresse die bei der Exception angegeben wurde im
->suchen ->zu Adresse springen, eingegeben habe, ist es falsch ?

Aufruf von IsFormSizeStored habe ich niergens gefunden, es ist ja eine vcl Methode ?
darum wird es vermutlich niergens zu finden sein, oder ?

Nein, das ist nicht falsch, es ist genau der Weg, wie ich auch nach Fehlern suche.

Das Problem ist nun halt leider, dass die Fehlerursache irgendwo "davor" im Programm liegt.

Mein Vorgehen ist in so einem Fall:

Debugger benutzen.
Einen Haltepunkt auf genau diese Zeile setzen.
Programm starten.

Wenn der Debugger nun an dem Haltepunkt stehen bleibt (oder durch Auslösen des Fehlers) im Debugger in Einzelschritten weitergehen und schauen, wo genau Du im eigenen Quelltext "landest". Das kann zuweilen dauern und sehr nervtötend sein.

Wenn Du nun (mehr oder weniger schnell) im eigenen Quelltext landest, dort den Quelltext vor dieser Stelle überprüfen.
Wird da was freigegeben, was nicht freigegben werden sollte?
Fehlerprüfung für alle Eventualitäten einbauen ...

Notfalls, wie weiter oben schon angeregt, "großflächig" auskommentieren, bis der Fehler nicht mehr auftritt. Dann stückweise die Auskommentierung wieder entfernen, um so der Fehlerstelle näherzukommen.

Eventuell mal hier schauen https://www.delphipraxis.net/187827-...einer-ist.html ab Post #19.

[akuk]

@Himitsu
%S,Danke, es ist nicht ein Fehler beim Kopieren, sondern schlicht vergessen gange.

[Scurra]

Zitat:

Zitat von himitsu (Beitrag 1462077)

Hat die Komponente Property/Verlinkungen zu anderen Komponenten auf der Form?

Dein Hinweis hat mich zu der Ursache des Problems geführt: Wir haben bei uns ein Formular A. Öffnen wir nun Formular B, dann setzen wir den Parent von Formular B auf Formular A. Wenn beim Schließen/im Destruktor von Formular B nun ein Fehler auftritt, dann wird zwar der Speicher von Formular B korrekt freigegeben (so wie du es auch beschrieben hast), aber Formular A wird nicht darüber informiert, dass das "Child" gar nicht mehr existiert. Wird nun auch Formular A freigegeben, dann wird noch einmal der Destruktor von Formular B aufgerufen und führt dann zur Zugriffsverletzung in der Methode IsFormSizeStored.

Dieses Beispiel, das man relativ einfach in einem TestProjekt nachstellen kann, verdeutlicht noch einmal, dass der Fehler nicht in der Methode IsFormSizeStored liegt, sondern dass es sich nur um einen Folgefehler handelt.

Ich vermute, dass das Problem beim Themenersteller eine ähnliche Ursache hat.

[akuk]

@Himitsu,@hoika,@klaus und weitere

Hallo,
danke für die viele Hinweise.

Ich habe jetzt das madExcept5 installiert.

Ich wundere mich, dass so etwas wichtiges
nicht zum Standard des Delphi RAD.

Endlich steht man nicht
wie Esel am Berg vor der Meldung "access violation at ..."
sondern kann man gezielt suchen.

Vielen Dank