External SIGSEGV, Bei Adresse...

[harrybonn]

Irgendwas habe ich verändert, beim Beenden des Programms (irgendwann nach Close, Closequery, destroy) erscheint jetzt immer die Meldung:

Projekt xyz hat Exception-Klasse "External: SIGSEGV" ausgelöst.

Bei Adresse F97FC6DC

Habe ich mit diesen Angaben irgendeine Möglichkeit die Stelle im Source-Code zu ermitteln, wo das Problem auftritt?

Es erscheint so ein Assembler-Fenster, aber wenn ich die o.g. Adresse dort eingebe, passiert nichts.

Edit: Den Fehler habe ich gefunden, habe eine Critical-Section zweimal freigegeben (im Destroy der Form und in einem Finalization-Abschnitt einer Unit).

Dennoch die Frage: Wie kann mir Lazarus helfen, mit Bordmitteln diesen Fehler zu finden?

[Socke]

Dennoch die Frage: Wie kann mir Lazarus helfen, mit Bordmitteln diesen Fehler zu finden?

Bei Objekten kannst du die folgendes machen:

• nach jeder Freigabe (Destroy oder Free) alle Objektreferenzen auf nil setzen (oder FreeAndNil verwenden)
• Compiler-Option -CR setzen

Dann erhältst du beim Aufruf einer virtuellen Methode eines bereits freigegebenen Objekts den Runtime-Fehler 210

Wenn das nicht geht: keine Chance bzw. saubere Regeln für das Erstellen und Freigeben von Objekten konsequent umsetzen.

[Warf]

Dennoch die Frage: Wie kann mir Lazarus helfen, mit Bordmitteln diesen Fehler zu finden?

Im ASM Debugger wird dir der Funktionsname angezeigt in der der Fehler auftritt, außerdem: SIGSEGV ist eine Segmentation Fault, also ein Zugriff auf einen nicht allozierten Speicherbereich, das sind eigentlich immer entweder noch nicht Initialisierte oder bereits gefreete Objekte/pointer. Am besten dann wenn der Fehler auftritt in der Funktion einen Breakpoint setzen und sich durchklicken, so kann man den Fehler auf eine Zeile reduzieren

[martin_frb]

F97FC6DC

Das ist wahrscheinlich im Kernel (oder ggf einel dll). Kann aber auch sein, das es im "nirgendwo" ist.

Wenn die CriticalSection ueber das Betriebsystem verwaltet wird, dann ist die 2te freigabe ein Aufruf ans OS mit illegalen Werten, and stuerzt im Kernel ab, oder kann irgendwo in einen zufaelligen speicher umgeleited werden (wo dann random data, statt assembler ist).

In solch einem Falle ist zum Zeitpunkt des Fehlers hauefig auch der Stack unlesbar. Es gibt keine moeglichkeit vom Fehler den Quellkode zu finden.

Man kann dann nur viele breakpoints setzen, und sich merken welche als letzter korrekt erreicht wurde. Im naechten Debug lauf setzt man dann mehr breakpoints .....