ActiveX and HeapTrace

[theo]

Ich habe gestern hier eine Frage gestellt: http://lists.freepascal.org/lists/fpc-d ... 30356.html
Leider habe ich keine Antwort bekommen.

Problem: Ich habe ein ActiveX Control "TAxcSpVoice" das nur bei eingeschaltetem Heaptrace beim "freen" crasht.

Gibt es hier jemand, der genug Einblick in die Materie hat, um eine Vermutung abzugeben, wieso das passiert?
Deutet es auf ein tiefer liegendes Problem hin, oder ist es ohne Heaptrace bedenkenlos?

[mse]

Deine Mail wurde vermutlich vom Listserver unterschlagen, Ich habe sie jedenfalls nicht bekommen.
Beim Mischen von referenzgezählten COM interfaces (ich denke, bei ActiveX sind immer irgenwo COM-Interfaces im Spiel) und TObject/TComponent.Free gibt es fast immer Probleme. Free() darf erst dann aufgerufen werden, wenn alle interface Referenzen _Release() aufgerufen haben und der Referenzzähler 0 erreicht hat. Mit TComponent kann man das nicht wissen, da Tcomponent _Addref() und _Release() ignoriert. Bei FPC kommt dazu, dass FPC immer mal wieder lokale interface Variablen erzeugt und wieder freigibt, welche nicht unter der Kontrolle der Programmierer stehen. Aber auch mit Delphi ist die Sache nicht wasserdicht. Wovon stammt TAxcSpVoice ab?

Martin

[m.fuchs]

Angekommen ist die Mail, aber ich weiß nicht ob die Mailingliste glücklich gewählt war. Statt FPC-Devel hätte ich eher FPC-Pascal genommen.

Was passiert denn wenn du auf das .Free verzichtest? Meldet HeapTrace dann ein Speicherleck? Kann es einfach sein, dass dein Objekt automatisch zerstört wird, wenn keine Referenz mehr daufliegt (Stichwort: COM-Interface)?

Möglicherweise hält HeapTrace ja irgendeine Referenz auf alle Objekte, was dann den Fehler erzeugt.

[theo]

Danke für die Antwort

Wovon stammt TAxcSpVoice ab?

TAxcSpVoice = Class(TActiveXContainer)

TActiveXContainer = class(TWinControl, IUnknown, IOleClientSite,
IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch)

[theo]

Was passiert denn wenn du auf das .Free verzichtest? Meldet HeapTrace dann ein Speicherleck?

Ja, tut es. Darum kann ich Heaptrace so eigentlich nicht verwenden, weil es entweder crasht oder Leaks anzeigt, die wahrscheinlich nicht unter meiner Kontrolle sind.

[theo]

Hier noch der automatisch generierte Code, falls es jemanden interessiert.

http://www.theo.ch/lazarus/SpeechLib_5_4_TLB.zip

[mse]

TAxcSpVoice = Class(TActiveXContainer)

TActiveXContainer = class(TWinControl, IUnknown, IOleClientSite,
IOleControlSite, IOleInPlaceSite, IOleInPlaceFrame, IDispatch)

TWincontrol stammt von TComponent ab welches _Addref() und _Release() folgendermassen -das heisst gar nicht- implementiert:

Code: Alles auswählen

 
function TComponent._AddRef: Integer;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
begin
  if Assigned(VCLComObject) then
    Result := IVCLComObject(VCLComObject)._AddRef
  else
    Result := -1;
end;
 
function TComponent._Release: Integer;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
begin
  if Assigned(VCLComObject) then
    Result := IVCLComObject(VCLComObject)._Release
  else
    Result := -1;
end;
 
 

Nun wird's schwierig.
Setzt TActiveXContainer VCLComObject?

[theo]

Nun wird's schwierig.
Setzt TActiveXContainer VCLComObject?

Weiss nicht, da kenne ich mich zu wenig aus.
Der Code ist hier einsehbar:
http://svn.freepascal.org/cgi-bin/viewv ... ot=lazarus

Danke.

[mse]

In activexcontainer.pas direkt nicht. Könntest du mal schauen, ob ein Vorfahre in Lazarus das tut?
Falls VCLComObject nirgendwo gesetzt wird (könntest du mit dem Debugger überprüfen) ist die Situation so, dass die COM Referenzzählung ausser Betrieb ist und TAxcSpVoice mit Destroy() freigegeben werden muss. Wie schon erwähnt darf das erst dann geschehen, wenn nirgendwo mehr eine interface Referenz auf das Objekt gehalten wird.
Falls die Referenzzählung in Betrieb ist, darf TAxcSpVoice.Free() nicht aufgerufen werden und der Speicher sollte automatisch freigegeben werden. Falls nicht ist das typisch für COM interface und bedingt dann mühsame Suche nach der Ursache...

[theo]

Danke ich schau am Abend mal nach.

Was hältst du von dieser Eigenschaft des ActiveXContainer:

201 {When set, binds ActiveX component to control.
202 When cleared, detaches the component from the control
203 If Classname is provided the ActiveX component will also be created and destroyed
204 automatically.}
205 property Active:boolean read FActive write SetActive;

[mse]

Was hältst du von dieser Eigenschaft des ActiveXContainer:

Aua. Damit habe ich mich zum Glück noch nie herumschlagen müssen.

Martin

[theo]

In activexcontainer.pas direkt nicht. Könntest du mal schauen, ob ein Vorfahre in Lazarus das tut?

Im ganzen Lazarus Source Tree kommt dieses Property nicht vor (Find in Files).
Nur in der FPC RTL, aber die kennst du ja.

[mse]

Dann können wir wohl davon ausgehen, dass die Instanz nicht durch die COM Referenzzählung freigegeben wird, es sei denn irgendein anderes Begleitobjekt erfüllt diese Aufgabe. Ich würde mal den Konstrukteur der Komponente (Ludo Brands) fragen, wie er sich die Sache vorgestellt hat.

[theo]

Ich würde mal den Konstrukteur der Komponente (Ludo Brands) fragen, wie er sich die Sache vorgestellt hat.

Naja, es funktioniert alles prima und es gibt im Normalbetrieb auch kein SIGSEGV, ausser beim "freen" mit eingeschaltenem HeapTrace.
Deshalb weiss ich gar nicht so richtig, ob das ein Bug ist, und wenn ja, ob da nicht evtl. HeapTrace falsch gewickelt ist.

Das herauszufinden war eigentlich der Grund für meine Frage. Je nachdem werde ich einen Bugtracker Eintrag machen.

[mse]

Was hier möglicherweise passiert, ist, dass du die Instanz freigibst und später _Release() oder eine andere interface Methode aufgerufen wird. Solange der Speicher nicht wiederverwendet wird, merkt man nichts davon. Heaptrace füllt freigegebenen Speicher mit Müll (0f0f0f0f) damit der Fehler sofort auftritt und nicht erst beim Kunden.

Martin.