Ich bekomme ständig eine AV:

Zitat:

--------------------------- Benachrichtigung über Debugger-Exception --------------------------- Im Projekt Glass.exe ist eine Exception der Klasse EAccessViolation aufgetreten. Meldung: 'Zugriffsverletzung bei Adresse 0045A32D in Modul 'Glass.exe'. Lesen von Adresse 00000014'. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen. --------------------------- OK Hilfe ---------------------------

Wie bekomme ich denn anhand dessen die Zeile heraus, in der sie ausgelöst wird?

Moderiert von Tino: Quote-Tags hinzugefügt

anhand dessen nicht, aber du kannst breakpoints setzen, wenn du wissen willst, woher der Fehler kommt.

mfg

Auf torry.net gabs mal ne Werbung für eine Software (Plug-in für Delphi oder Kompo, kA), mit der man bequem die genaue Zeile herausfinden konnte, sobald eine AV auftritt.

Wozu? Nennt sich Delphi-IDE und ist zu finden unter Suchen --> Laufzeitfehler ...

Lediglich Debug-Infos müssen aktiv sein UND der Debugger muss grad laufen.

Ggf. einfach unter Ansicht --> Debug-Fenster mal den Call-Stack herauskramen und ein wenig rumklicken ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Naja, diese Software gabs, wie die heißt weis ich auch nicht mehr, war aber nicht ganz billig.

Aber es sollte ja auch möglich sein ohne die Software rauszubekommen wo die AV geschmissen wird.
Geh mal so vor. Debug mal deine Anwendung und setzt alle 20 - 30 Zeilen (oder auch weniger, je nachdem wie
groß dein Code ist) einen Breakpoint. Dann lässt du immer stückweise laufen.
So kannst du es enger eingrenzen. Dann weißt du zwischen welchen der Fehler liegt,
jetzt die Breakpoints dort enger machen.

Kann sein, dass das allerdings nichts zutage fördert, da da dann eine harmlose Anweisung steht.
In diesem Falle mal prüfen, ob du irgendwo einen uninitialisierten Pointer oder sonst irgendwas in
die Richtung machst.

Oder eben so wie gerade oben gepostet.

BenBE hat folgendes geschrieben:

Wozu? Nennt sich Delphi-IDE und ist zu finden unter Suchen --> Laufzeitfehler ... Lediglich Debug-Infos müssen aktiv sein UND der Debugger muss grad laufen.

Und das wichtigste: in PE-Versionen gibt's das nicht. Nur Pro/Ent/usw.

Aber eigentlich sollte, wenn er denn Debug-Infos hat, der Debugger doch selber ungefähr die Zeile anzeigen...

Alternativ (für die armen PE-Benutzer): Detailliertes MAP-File erzeugen lassen (Projekt --> Optionen --> Linker --> Mapfile --> Detailliert)

Dort dann einfach nach der Adresse suchen:

Hinweise:
- Die Basisadresse der EXE muss abgezogen werden (meist $00400000)
- Die Start-Adresse des Code-Segments muss abgezogen werden (meist $00001000)
- Gesucht ist die größte Adresse im Mapfile, die kleiner oder gleich der Fehler-Adresse ist.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Wozu? Nennt sich Delphi-IDE und ist zu finden unter Suchen --> Laufzeitfehler ... Lediglich Debug-Infos müssen aktiv sein UND der Debugger muss grad laufen. Ggf. einfach unter Ansicht --> Debug-Fenster mal den Call-Stack herauskramen und ein wenig rumklicken ...

Wenn ich Suchen => Laufzeitfehler suchen verwende und die Adresse 0045A32D eingebe, komme ich ins CPU-Fenster. Wie schließe ich denn daraus auf die entsprechende Codezeile?

Thema hat sich erledigt: Ich hatte im Konstruktor einer von TImage abgeleiteten Klasse inherited Create(Aowner); vergessen.

prinzipiell kann ich dir für sowas das Tool MadExcept empfehlen.
Damit kannst du in vielen Fällen bei Exceptions oder Acces Violation sogar die Quellcodezeile rausbekommen, die das Problem verursacht hat. Das vereinfacht das Debuggen schon erheblich!

madExcept kostet (und nicht grad wenig) und bläht die EXE auf ... Wenn man's kostenlos haben will, nimmt man aus Omorphia das Debug-Interface (ODbgIntf.pas), schreibt sich seinen Handler und kann die Meldung sogar noch vor Delphi abfangen, bekommt vollständige Debug-Infos (vorausgesetzt MAP-File ist erzeugt, ...) und nen vollständigen Stacktrace. UND hat den Vorteil, dass man nem Endkunden ne EXE ohne Debug-Infos geben kann, womit dieser keine Rückschlüsse auf den Programmaufbau ziehen kann, außer er zerlegt das Teil vollständig, man aber leicht anhand der EXE und der MAP-File die genaue Fehlerzeile rausbekommt.

Außerdem hat madExcept (zumindest in den Versionen, wo ich's getestet hatte) einige Nebenwirkungen gehabt, weil es sich einfach überall reingehängt hat.

Einziger wesentlicher Nachteil am ODbgIntf ist, dass es jegliche Exceptions abfängt, was aber, da Exceptions eh die Ausnahme sein sollten, kein Problem ist. Und das ODbgIntf ist nichts für Leute, die nicht wissen, was sie tun ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

ja da hat BenBE schon recht, dass Mad Except die EXE sehr aufbläht.
Ich denke, dass das für die persönlichen Zwecke umsonst ist...? Naja auf jeden Fall kann man das ja lokal zum Testen in die EXE mit hineinkompliieren und wenn man das Produkt dann ausliefert wieder rausnehmen.