Hallo allerseits,

Ich habe mal wieder ein sehr unschönes Problem. Und zwar stirbt Thorium in Zeile elf in unten stehendem Code.

Klar, damit kann nun keiner was anfangen. Darum geht es auch nicht wirklich. Das Hauptproblem ist nicht, dass er dort abstürzt, sondern, dass es keine Fehlermeldung oder ähnliches gibt, die Details darüber gibt, was eigentlich passiert. Der Prozess beendet sich einfach, wird aber nicht vom Betriebssystem beendet, sondern ordnungsgemäß abgeschlossen. Nicht aber behandelt werden irgendwelche Finallys, die noch in der Aufrufshierarchie weiter oben stehen.
Der Debugger sagt dazu auch nichts. Nach dieser Zeile heißt es einfach "Execution finished".

Jetzt frage ich mich, was kann der Grund für soetwas sein? Hat irgendjemand schon Symptome dieser Art beobachtet? Habt ihr *irgendwelche* noch so vagen Vermutungen, wonach ich ausschau halten soll?

Es wird definitiv *nicht* zu viel Speicher alloziiert. Bei dem fraglichen Aufruf der Methode ist der Parameter = 64, sodass nur 64*32 Bytes reserviert werden sollen.

greetings *verwirrt bin*

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Läuft vielleicht noch ein anderer Thread parallel, in dem das Programm beendet wird?

Hast du den Optimizer drausen? Sonst zeigt der Debgger vielleicht quark an.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also das sich eine Anwendung urplötzlich beendet kenne ich. Allerdings lag es daran an einer C++ DLL die im Falle eines Fehler ein C++ Close (Halt in pascal) aufgerufen hat. Das sorgt dafür, dass die Anwendung beendet wird. Und zwar kommentarlos und ohne, dass man etwas dagegen tun kann. Allerdings denke ich nicht, dass das bei dir der Fall sein könnte.

Wenn ich eines bei Pointern gelernt habe, dann das man sich nie sicher sein kann an welcher Stelle es tatsächlich das Problem gibt. Es kann auch gut sein, dass dein Pointer irgendwie im Eimer ist und der Speichermanager beim Freigeben merkt, dass er es ist und deswegen aussteigt. In Delphi kommt in solchen Fällen klassischerweise eine Invalid Pointer Operation. Keine Ahnung wie FreePascal da reagiert. Eventuell solltest du mal schauen wie sich deine Pointer verhalten.

Was sagt denn dein ExitCode? Wenn eine Anwendung beendet wird liefern die normalerweise einen Exitcode zurück.

Philip: Nein, leider nicht. Also zumindest keinen, den ich gestartet hätte.

Flash: Ist ja leider nicht nur der Debugger, sondern auch meine WriteLns, die ziehmlich genau diese Zeile aus Ausstiegspunkt bezeugen. Optimierungen ausgemacht - ändert leider nichts.

Lossy eX: ExitCode ist 1. Gibt ja kaum etwas aussageloseres ...
Ja, ein Halt vermute ich auch. Aber leider wüsste ich nicht, wo das auftreten sollte. Obwohl ... Moment ... in FreeMem reintracen geht nicht und als ich gerade mal in den Sourcecode dazu reingscahut habe, ist mir eingefallen, dass ich ja die Heaptrc.pas benutze. Und sieheda, im log steht tatsächlich was interessantes.

Und ohne Heaptrc.pas (welches ja einen separaten Speichermanager implementiert), läuft das ganze auch durch - bis es dann versucht, den Speicherblock weiter zu benutezn. Da knallts dann.
Ich weiss allerdings nicht so recht, was mir das sagen soll. Der Pointer an sich ist eigentlich in Ordnung, das Auslesen der Größe des Speicherblocks funktioniert auch so weit ... Werde mal schauen, was heaptrc mit dieser Meldung meint. Aber danke für die Hinweise, die haben den nötigen Gedankengang induziert, um auf Heaptrc.pas zu kommen.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Zur Lösung hat schließlich valgrind geführt, welches ich bei dieser Gelegenheit gleich allen Linux-Usern empfehlen will. Valgrind ist ein interessantes Debugging-Tool, welches mit dem richtigen Switch auch bei FPC-Programmen sehr hilfreichen Output produziert. Zum Beispiel:


Der Fehler war letzendlich, dass ich beim Einfügen einer neuen Instruktion (irgendwo in die mitte) immer ein Element zu viel nach hinten verschoben habe. Das ging so lange gut, bis das mal genau in dem Moment passierte, wo der reservierte Speicher exakt gefüllt wurde (FCount = FCapacity). Dann schrieb er logischerweise über den Rand, zerstörte damit die Signatur, die Heaptrc ans ende schreibt, was heaptrc dann beim realloc alles andere als gefallen hat.

nochmal danke für die hinweise

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb