Externer SIGSEGV ohne ersichtlichen Grund?

[Leberecht]

Hallo,

arbeite an einem Projekt zur ActiveX-Steuerung einer externen Anwendung und es klappt alles soweit. Die Kommunikation hatte ich bisher über ein
Objekt ohne Event-Support gelöst. Jetzt wollte ich gern Events der externen Anwendung verarbeiten und habe die Objektversion mit Event-Support
benutzt. Das ganze funktioniert ähnlich gut wie die alte Lösung, auch die Events werden korrekt verarbeitet. Alles ist bestens bis auf eines: Wenn
ich meine Lazarus-Anwendung schliesse, gibt es IMMER einen externen SIGSEGV und ich weiss einfach nicht warum bzw. was ich tun kann um das zu vermeiden.
Habe mich an die Anleitung von "http://wiki.freepascal.org/LazActiveX" gehalten und das Objekt zum Schluss auch mit .Free freigegeben.

Erstellung:

Code: Alles auswählen

var
oEBP:TEvsEBPControl;
 
oEBP:=TEvsEBPControl.Create(Self);
oEBP.OnTrackEntered:=@gleisBetreten;
 
geht alles. Zum Schluss in Form.Close():
oEBP.Free;
oEBP:=nil;  //egal -bewirkt nichts

Es ist übrigens egal, ob ich eine Funktion an einen Event binde oder nicht. Der SIGSEGV kommt immer, es reicht schon wenn ich nur das Objekt erstelle.
Auch wenn ich das .oEBP.Free ins Form.Destroy reinmache wie in der Anleitung -geht trotzdem nicht. Habe die Fehlermeldung als Screenshot angehängt.
Der Befehl "oEBP.Free;" löst scheinbar den SIGSEGV aus. Wenn ich ihn weglasse kommt der Fehler trotzdem, vermutlich weil er dann automatisch aufgerufen wird.

[theo]

Hast du eine neue FPC Version?

[Leberecht]

Habe die 2.6.2, zu Lazarus 1.0.8.

[theo]

Kann sein, dass Trunk (FPC 2.7.1) Abhilfe schafft. ActiveX ist noch ziemlich in Entwicklung.

[Leberecht]

Ich hab jetzt rausgefunden, woran es lag: Heaptrc. Wenn ich das ausschalte gibts keinen SIGSEGV mehr. Ist nur dumm, da ich schon noch gern wüsste, wo ich MemLeaks habe. Gibts eigentlich alternative Programme für Lazarus mit denen ich auf Memory Leaks prüfen kann?

[theo]

Probier einfach mal so:

oEBP:=TEvsEBPControl.Create(nil);

Nil statt Self, dann sollte es nicht autom. destroyed werden. Dann zeigt dir heaptrc wahrsch. ein Leak an, aber wenn es nur das eine ist, ist es OK.

[Leberecht]

Ja, das klappt wenn ich gleichzeitig die .Free -Methode nicht aufrufe. Allerdings muss ich dann immer daran denken, bei der Release-Verson des Programms das .Free wieder zu aktivieren, dann den Speicher muss er ja freigeben. Heaptrc kann das wohl nicht tracen wegen der übergreifenden Speicherzugriffe mit dem externen Programm. Villeicht finde ich ja ein externes Progamm das einfach nur meine Lazarus .exe vom Start bis zum Ende überwacht und die Speicherdifferenzen anzeigt.

[theo]

Ja, das klappt wenn ich gleichzeitig die .Free -Methode nicht aufrufe. Allerdings muss ich dann immer daran denken, bei der Release-Verson des Programms das .Free wieder zu aktivieren, dann den Speicher muss er ja freigeben.

Wäre nicht so schlimm, denn eigentlich erledigt das das Betriebssystem bei Programmende.