SystemException Ursache finden

[akuk]

Hallo
Suche seit Wochen nach der Ursache der SystemException.
Meine Entw.Umgebung ist : Delphi RAD 10.3m Windows 7
An den Stellen im Programm vo ich vermute dass die Exception auslöst habe ich probiert
die Exception abzufangen mit :
try ..//verdächtige Sequenz
except
on e:Exception do
raise Exception.Create(format('Name der Sequenz',[e.Message]));
end;

Es wurde immer die selbe Exception angezeigt:

Exception Klasse .. 5 access violation at ....
aber nie meine Message (Name der Sequenz)

Suche ich am falschen Orten ?
Oder gibt es eine andere Möglichkeit die Ursache resp. die auslösende Sequenz zu finden ?

[scrat1979]

Haltepunkt setzen und mit dem Debugger schauen wo es knallt. Das wäre meine erste Handlung bei der Fehlersuche.

[Delphi.Narium]

Zu Delphi 7-Zeiten ging:

Programm im Debugger starten.
Laufenlassen, bis der Fehler auftritt. Im Idealfall geht der Debugger zu der Stelle, an der der Fehler auftritt.

Wenn nein: Fehleradresse aus der Fehlermeldung nehmen.

In der IDE im Menü "Suchen" den Menüeintrag "Laufzeitfehler suchen ..." auswählen, im Eingabefenster die Fehleradresse aus der Fehlermeldung eingeben und suchen lassen.

Mit etwas Glück kommt man an die genaue Fehlerstelle.

Bei 'ner Accessvolation wird meist auf etwas zugegriffen, was es nicht (mehr) gibt. Der Fehler kann also auch außerhalb der verdächtigen Routine liegen, höchstwahrscheinlich "irgendwo kurz vor dem Aufruf der verdächtigen Routine" oder der Fehlerbehandlung per Try / Except.

[himitsu]

Es gibt Erweiterungen, welche auch im Programm einen Stacktrace bei Fehlermeldungen anzeigen.
z.B. Eurekalog, MadExcept oder jclDebug/jclHookExceptions (JEDI)

pssst:

Delphi-Quellcode:

Format('Name der Sequenz', [E.Message])

> das fehlende %s ist bestimmt nur ein Fehler beim Kopieren,
aber Format? >

Delphi-Quellcode:

raise Exception.CreateFmt('Name der Sequenz: %s', [E.Message]);

:zwinker:

Per se ist es eigentlich schöner die originale Exception beizubehalten, denn so manche Exception-Klasse hat Zusatzinfos, die sonst verloren gehen.

Delphi-Quellcode:

except
  on E: Exception do begin
    E.Message := 'Name der Sequenz: ' + E.Message;
    raise;
  end;
end;

Aber gerade bei System-Exception hat Delphi ein echt saublödes Verhalten, denn beim Re-Raise kann es passieren (z.B. wenn die Exception durch die Messagebehandlung von Windows rauscht),
dass Delphi die originale Windows-Exception wiederherstellt und dabei der geänderte Text flöten geht.

Hier könnte man nun mit verschachtelten Inner-Exceptions arbeiten,

Delphi-Quellcode:

// TApplicationEvents.OnException
procedure TForm1.ApplicationEvents1Exception(Sender: TObject; E: Exception);
var
  S: string;
begin
  while Assigned(E) do begin
    if S <> '' then
      S := S + sLineBreak + sLineBreak;
    S := S + E.ClassName + ': ' + sLineBreak + Trim(E.Message);
    E := E.InnerException;
  end;
  ShowMessage(S);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  try
    Tag := Tag div Tag;  // Division durch 0
  except
    Exception.RaiseOuterException(Exception.Create('Name der Sequenz'));
  end;
end;

Code:

Exception:
Name der Sequenz

EDivByZero:
Division durch Null

Delphi-Quellcode:

// falls man etwas hat, dass sich bei Exception.GetStackInfoStringProc registriert hat und den Stacktrace liefert
procedure TForm1.ApplicationEvents1Exception(Sender: TObject; E: Exception);
var
  S, T: string;
begin
  //T := E.StackTrace;  // Stack der äußeren Exception, aber uns interessiert ja die Innersten/Ursprünglichen viel mehr
  while Assigned(E) do begin
    if S <> '' then
      S := S + sLineBreak + sLineBreak;
    S := E.ClassName + ': ' + sLineBreak + Trim(E.Message);
    if not (E.InnerException) and Assigned(E.StackInfo) then
      S := S + sLineBreak + sLineBreak + 'Stacktrace:' + sLineBreak + E.StackTrace;
    E := E.InnerException;
  end;
  //if T <> '' then
  //  S := S + sLineBreak + sLineBreak + 'Stacktrace:' + sLineBreak + T;
  ShowMessage(S);
end;

aber der hauseigene Fehlerdialog von Delphi ist ein bissl "dämlich" und Zeigt sowas nicht an. :roll:

[akuk]

Hallo
Vielen Dank für Euere Hilfe.
Kann dies eine Exception auslösen ?

(aus vcl.Forms) :

function TCustomForm.IsFormSizeStored: Boolean;
begin
Result := AutoScroll or (HorzScrollBar.Range <> 0) or (VertScrollBar.Range <> 0);
end;

[Delphi.Narium]

Ja, wenn das Formular vorher nicht erstellt oder vorher freigeben wurde.

Hast Du dort ein konkretes Problem?

Im Debugger die Werte alle anschauen.

Der Debugger müsste Dir sagen können, ob da irgendwas nicht initialisiert ist ...

Aber zugegeben: An soeiner Stelle würde ich keinen Fehler vermuten.

Wie bist Du dahinter gekommen, dass dort ein Fehler sein könnte?
Könntest Du eventuell den Quelltext, der zum Aufruf von IsFormSizeStored oder den Aufruf von IsFormSizeStored enthält posten?

Eventuell lässt sich die Fehlerursache dadurch weiter einkreisen.

[Scurra]

In unserer Software bekommen wir gelegentlich auch Fehlerberichte von Fehlern in dieser Funktion. Bei uns liegt es an einer fehlerhaften Komponente, die im Destruktor gelegentlich Exceptions auslöst. Der Destruktor wird wiederum vom Destruktor des Formulars aufgerufen.
Nach meinem Verständnis wird dadurch das Formular, auf dem die Komponente liegt, nicht freigegeben (oder evtl. nur die Referenz auf unsere Formularvariable nicht zurückgesetzt), was beim Schließen der Anwendung dazu führt, dass die Anwendung erneut versucht, das Formular freizugeben. Das führt dann zu dem Fehler in der Methode IsFormSizeStored. Das liegt aber nicht an der Funktion, sondern ist nur ein Folgefehler eines vorher auftretenden Fehlers.

[hoika]

Hallo,
schrittweise Code ausklammern, bis der Fehler nicht mehr kommt.

[himitsu]

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

Bei selbstgebauten Komponenten wird gern vergessen Diese ordentlich zu behandeln.
z.B. TDataSet und TDataSource, wenn du das DataSet löschst, dann wird die DataSource informiert und setzt ihr DataSet-Property auf nil.




Die Komponente wird eigentlich immer freigegeben, aber bei Dingen in der Komponente...

Wenn es beim Freigeben knallt, dann bricht das ja zwischendrin ab,
aber im Constructor und Destructor befinden sich ein Try-Except, was zumindestens den Speicher des Objekts selbst abräumt.

[akuk]

@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 ?

[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