Exception nach Programmende

[Scotty]

Meine destroy-Routinen werden alle sauber durchlaufen und heaptrace meldet, dass alles freigegeben sei. Allerdings bekomme ich danach eine AV. Sollte ich dem Problem nachgehen (oder ist das eine Frage von heaptrc) und wenn, wo?

Code: Alles auswählen

Heap dump by heaptrc unit
1237830 memory blocks allocated : 124174141/128579336
1237830 memory blocks freed     : 124174141/128579336
0 unfreed memory blocks : 0
True heap size : 1867776
True free heap : 1866880
Should be : 1867776
An unhandled exception occurred at $00000000004ABFA4 :
EAccessViolation : 
  $00000000004ABFA4
 

[theo]

In welchem Zusammenhang? COM/OLE/ActiveX oder sowas?

[Scotty]

In welchem Zusammenhang? COM/OLE/ActiveX oder sowas?

Linux (gerade eben nur damit getestet). Interface mit corba, OpenGl, Threads, Synapse... alles drin im Programm
(Mir ist klar, dass die Frage sehr allgemein gestellt ist.)

[theo]

Ich hatte sowas auch schon mal im Zusammenhang mit ActiveX.
Das war nur mit heaptrc ein Problem. Ich habe es einfach ignoriert und das Prog. läuft und schliesst seither ohne zu mucken.

[marcov]

Kann auch einfach weg sein das dein Programm RTL/heap State überschriebt, und das beim beenden das bemerkt wird.

[Socke]

Meine destroy-Routinen werden alle sauber durchlaufen und heaptrace meldet, dass alles freigegeben sei. Allerdings bekomme ich danach eine AV. Sollte ich dem Problem nachgehen (oder ist das eine Frage von heaptrc) und wenn, wo?

Ja, du musst dem nachgehen. Bei einer Access Violation greift dein Programm auf ein Stück Arbeitsspeicher zu, das ihm nicht vom Betriebssystem zugeordnet wurde. Das ist immer ein Fehler und gehört behoben. Die Unit heaptrc hilft häufig dabei diese Fehler zu finden.
Da dein Stacktrace wenig aussagekräftig ist, hilft wohl zuerst nur der Debugger. Damit kannst du definitiv herausfinden, wo auf den Speicher zugegriffen wird (eine Variable, ein Objekt, etc.), auch wenn dies in der LCL/RTL liegen sollte. Bei einem Zweiten Durchlauf setzt du im Debugger eine Haltebedingung auf die Änderung dieser Variablen.

[Scotty]

Da dein Stacktrace wenig aussagekräftig ist, hilft wohl zuerst nur der Debugger.

Ich debugge ohne Probleme durch meinen Code (d.h. mainform.destroy und co). Wie kann ich da weiter machen?
gdb meldet, wenn ich es in der Konsole und ohne heaptrc laufen lasse, "[Inferior 1 (process 13611) exited normally]".

[mse]

Zuerst alles (auch die FPC RTL) mit debug info kompilieren. Danach in der IDE "stop at exception" aktivieren. Vermutlich passiert die exception im finalize Abschnitt einer lib.

[Euklid]

Meine destroy-Routinen werden alle sauber durchlaufen und heaptrace meldet, dass alles freigegeben sei. Allerdings bekomme ich danach eine AV. Sollte ich dem Problem nachgehen (oder ist das eine Frage von heaptrc) ....?

Hast Du mal Valgrind probiert?

[mschnell]

Exceptions bei Programm-Ende passieren sehr leicht bei Threads, die nicht vor beenden des Mainthreads sauber terminiert sind. Ein Thread kann sich nur selber beenden. "Abwürgen" führt oft zu solchen Problemen.

-Michael

[Scotty]

Threads laufen (noch) nicht, hab ich geprüft - nur Start und Beenden (wobei natürlich einiges initialisiert wird).

Valgrind liefert eine Menge an Informationen und bestätigt den Leak (der gesamte Output ist 1.7MB groß). Aber wie komme ich an Zeilennummern, Namen von Objekten o.ä.?

Code: Alles auswählen

==1646== LEAK SUMMARY:
==1646==    definitely lost: 24,046 bytes in 61 blocks
==1646==    indirectly lost: 53,106 bytes in 2,182 blocks
==1646==      possibly lost: 1,763,901 bytes in 7,319 blocks
==1646==    still reachable: 1,329,522 bytes in 8,940 blocks
==1646==         suppressed: 0 bytes in 0 blocks 

Code: Alles auswählen

==1771== Collected : 8385404870

-MObjFPC -Scghi -CX -CirotR -O1 -g -gl -gv -XX -vewnhib -Fl/opt/gnome/lib -FuSynapse -Fu... -l -vm5024,5057 -dLCL -dLCLgtk2