Zur Laufzeit, Zeilennummer feststellen

[himitsu]

Application.HandleException ist da, wo es bei dir schon raus ist.

Delphi-Quellcode:

function HandleMessage;
try
  CallWindowsEvents;  // hier hat es in einer unterfunktion geknallt
except
  HandleException;  // aber hier ist dein HandleException-Event drin, also ist ein Stacktrace von HIER aus sinnlos
end

System.ExceptObject ... das entspricht dem on E: Exception im EXCEPT-Block
System.ExceptAddr ... hier hatte es geknallt
System.ReturnAddress ... mein Caller (bzw. der Befehl danach)

Schau dir mal die Exception-Klasse genau an. Da kann man sich für die Stacktrace-Behandlung registrieren.
Also während die Exception ausgelöst wird ... da kannst du den Stacktrace auslesen und innerhalb des aktuellen Exception-Objektes speichern. (Delphi bietet nur die Zugangspunkte, aber ohne eigene Funktion)
Und in der anschließenden Exceptionbehandlung kannst du über das Exception-Objekt an dessen Stacktrace wieder rankommen.

[günni0]

Wie loggt ihr denn dann Fehler wenn nicht mit einer Exception-Prozedur? Ich kann schlecht überall try-except hinschreiben.

[himitsu]

Mit Try-Except und alles was wir vergessen haben über TApplicationEvents.OnException (nicht direkt an Application)

[günni0]

Also doch try-except. Ich dachten immer man soll sauber funktionierenden Code schreiben und try-except sei nur eine Notlösung.

Zitat:

über TApplicationEvents.OnException (nicht direkt an Application)

Den Teil verstehe ich nicht. Dann hat man ja aber wieder keinen Zugriff auf genaue Fehlerquellen.

[himitsu]

Hier haben wir ein in Jahrzehnten gewachsenes Programm aus mehreren EXEn, vielen DLLs und massig BPLs.
Das wurde von Turbo Pascal (DOS) über Delphi 7 (Windows), aktuell Delphi XE und parallel neu für 10.x .
533 vorwiegend eigene Units, ~60 Projekte (EXE/DLL), ~30 Packages und vielen Fremdkomponenten.
Wo mehrere Leute drin rumpfuschen .... mal ehrlich, erwartest du wirklich, dass es da alles reibungslos funktioniert?

Neben Eurekalog sind da noch ein paar eigene Exceptionbehandlungen mit Erweitern der Exception-Message, da Eurekalog auch nicht immer den Stacktrace ausreichend aufbauen kann.

[Nathan]

Hatten dies auch schon, das in unseren Exe beim Kunden AVs wie "Access violation at address 005CDF76 in module 'DummyProject. exe'. Read address 00000000." aufgetreten. Hat dann immer jeder gesagt, weis nicht wo der Fehler liegt. Bin dann hin gegangen und lies die Exe mit MAP Files kompilieren. Passend zur Exe Version wurde die entsprechende MAP Datei gesichert. Verteilt an den Kunden wurde nur die Exe.

Hat jetzt ein Kunde eine AV, kann ich mit einem selbst geschriebenen Programm, Zeilennummer der Exception filtern.

Das Programm hab ich unter Github https://github.com/Thurnreiter/Thurnreiter.MapFile veröffentlicht.

Ein Aufruf von "NathanMapFile.exe -MapFilename:.\DummyProject.map -CrashAddress:$005CDF76" ergibt dann:

Offset: 6
Codeline: 34
Startaddress from Module: $001CCCA0
Name of procedure from address: Unit1.TForm1.Button1Click
Sourcename from address: Unit1.pas

Voraussetzung ist, zur Exe eine passende MAP Datei. Es ist dann auch keine IDE nötig. Vielleicht hilft dir das Programm was.

[KodeZwerg]

Hallo Nathan, verstehe ich das richtig, ich binde in meinem Projekt keinen Code von Dir ein sondern kompiliere es mit .MAP Datei Erzeugung, Kunde bekommt .exe, ich behalte .MAP.
Nun verwende ich Dein Tool wie Du es beschrieben hast und fertig?
Falls das der Fall ist, könntest Du eventuell auch ein binary bereitstellen?
JCL wollte ich nicht installieren um dein Tool kompilieren zu können um JCL danach gleich wieder los zu werden.

[Nathan]

Funktioniert genau wie Du sagst. Musst kein Code von mir einbinden. Nur deine Anwendung mit MAP Files erzeugen. Die MAP Files liefere ich nicht aus, da sonst die Update zu groß werden. Halten aber für jeder Exe Version welche veröffentlicht wird, das entsprechende MAP File vor. Tritt dann beim Kunden eine unerwartete AV auf, kann ich meistens den Fehler genauer einschränken und muss nicht hoffen, das der Fehler reproduzierbar ist.
Ist halt leider nur eine Konsolenanwendung.

Bindary für Win32 liegen auf GutHub unter https://github.com/Thurnreiter/Thurn...ster/Bin/Win32

[KodeZwerg]

Vielen Dankeschön für prompte Antwort Nathan!
Ja da hätte ich auch darauf kommen können mal ins \bin\ zu gehen, tut mir leid dafür. Ich hab nur "clone or download" beim ersten mal geklickert.
Ich habe es gerade mit einer TestApp die bewusst Fehler erzeugt ausprobiert. Resultat = It works!
Ich bin begeistert und teste Garantiert noch diese oder jene Fehler aus um zu schauen was dein Tool darüber sagen kann.
Das würde mich von MadExcept befreien, was ja auch ein ganz schöner Brocken ist.
Mein Empfinden nach Ersten Test = Ich finde es Klasse! Console oder GUI ist mir in diesem Fall mehr als egal.

[CCRDude]

Nur die .map-Files zu verwenden kann manchmal helfen, aber was genau hilft es Dir, wenn Fehleradresse + .map-File Dir dann sagen, dass der Fehler in StrToInt etwa liegt? Doch nur, dass irgendwo im gesamten Programm ein String nicht ordentlich in eine Zahl umgewandelt werden kann.

Deshalb wurde weiter oben ja schon mehrfach erwähnt, dass erst Callstacks wirklich helfen - nur so kommst Du auch an den Kontext!

Und den callstack ordentlich herauszufinden ist halt eine Herausforderung, weswegen madExcept, JclDebug, EurekaLog etc. erprobte Erleichterungen sind.