MemoryLeak bei TList<IMyInterface>

[stahli]

Hmm, offenbar sind gegenseitige Referenzen mein Problem.

Ich habe ein MyIntf, das eine Eigenschaft IMyParentList unterstützt.
Das Interface weiß also, von welcher Liste es kontrolliert wird und kann diese über bestimmte Änderungen informieren.

Jetzt wird aber wohl die IMyParentList nicht freigegeben weil MyIntf nicht freigegeben wird und anders rum.
In der Richtung scheint das Problem zu liegen. Heute Abend geht´s dann weiter.

So wie ich das verstehe, fällt das thematisch wohl auch in diesen Bereich: http://www.delphipraxis.net/184100-weak-tlist.html


Aber mal noch 2 andere Dinge:

Warum sind denn _AddRef und _Release nicht virtuell? Dann könnte man sich mal schnell reinhängen und die Ref-Änderungen leichter nachvollziehen.

Sehr verwirrend finde ich auch das Verhalten im Constructor.

Delphi-Quellcode:

constructor TFoo.Create;
begin // RefCount = 0
  IrgendwasInZeileEins; // RefCount = 1 ... hier nur um zu zeigen, dass es nicht mit inherited zusammenhängt
  inherited; // RefCount = 1
end; // RefCount = 0

..
  FooObj := TFoo.Create; // RefCount = 0
  FooIntf := TFoo.Create; // RefCount = 1
..

Der RefCounter wird erst mal erhöht und dann wieder auf 0 reduziert.

In bestimmten Fällen scheint er aber auf 1 zu bleiben und das FooIntf hat dann RefCount = 2. Bisher habe ich nicht gefunden, wann das auftritt.
Irgendwas muss da im Contructor anders laufen (und meine Vermutung, dass ich da etwas vermurkst habe, konnte ich bisher nicht bestätigen).

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1291604)

Hmm, offenbar sind gegenseitige Referenzen mein Problem.

http://www.delphipraxis.net/184100-weak-tlist.html usw.
Jupp, fällt in den Bereich. :stupid:

Zitat:

Warum sind denn _AddRef und _Release nicht virtuell

Das hab ich mich auch schon gefragt. :wall:

Du kannst aber (theoretisch) das Interface neu einbinden und auf die neuen/eigenen Methoden verweisen.
Früher hatte ich einfach nur selber das IInterface implementiert, aber wenn du jetzt mal in TInterfacedObject nachsiehst, was dort gemacht wird ... das will ich nicht mehr selber (nach)machen. :freak:

[Der schöne Günther]

Zitat:

Zitat von stahli (Beitrag 1291604)

Warum sind denn _AddRef und _Release nicht virtuell? Dann könnte man sich mal schnell reinhängen und die Ref-Änderungen leichter nachvollziehen.

Ich hab das Thema zwar nicht mitgelesen, aber das hat mich auch schon mal geärgert. Dass man die Methoden aus Performance-Gründen nicht virtuell macht kann ich verstehen, aber wie toll wäre es, sie bei

Delphi-Quellcode:

IFDEF DEBUG

doch virtuell zu haben?

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1291604)

Sehr verwirrend finde ich auch das Verhalten im Constructor.

Delphi-Quellcode:

constructor TFoo.Create;
begin // RefCount = 0
  IrgendwasInZeileEins; // RefCount = 1 ... hier nur um zu zeigen, dass es nicht mit inherited zusammenhängt
  inherited; // RefCount = 1
end; // RefCount = 0

..
  FooObj := TFoo.Create; // RefCount = 0
  FooIntf := TFoo.Create; // RefCount = 1
..

Der RefCounter wird erst mal erhöht und dann wieder auf 0 reduziert.

Einfach mal den Source von TInterfacedObject lesen.

[stahli]

Ja, habe ich natürlich auch vor (hatte ich natürlich auch schon mal oberflächlich).

Aber egal, was dort passiert, das dürfte doch erst bei "inherited" abgearbeitet werden und nicht bei "begin"!?
Daher bin ich davon ausgegangen, dass der Linker da irgendwas tut, das man innerhalb der Klasse nicht wirklich erkennen kann.

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1291625)

Aber egal, was dort passiert, das dürfte doch erst bei "inherited" abgearbeitet werden und nicht bei "begin"!?
Daher bin ich davon ausgegangen, dass der Linker da irgendwas tut, das man innerhalb der Klasse nicht wirklich erkennen kann.

Kann man schon erkennen, wenn man weiß, wo man suchen muss:

Zitat:

// Set an implicit refcount so that refcounting during construction won't destroy the object.
class function TInterfacedObject.NewInstance: TObject;

[Uwe Raabe]

Das Pendant dazu steht dann unter

Delphi-Quellcode:

procedure TInterfacedObject.AfterConstruction;

[stahli]

Ok, danke, so tief war ich da noch nicht eingestiegen (verstehe das auch jetzt nur ansatzweise).


Das Problem RefCounter mal 1 mal 2 konnte ich jetzt etwas eingrenzen:


Von der Factory wird nur ein Objekt erzeugt und als Interface zurück gegeben.

Wenn ich das Ergebnis einer lokalen Interfacevariable zuweise ist RefCounter 1.
Die gleiche Zuweisung zu einem privaten Feld führt zu RefCount = 2.

Ich kann mir vorstellen, dass es daran liegt, dass die Methode (aktueller Scope) auf das Feld zugreift und die Klasseninstanz als solche auch nochmal.
Ist das so oder lässt sich das anders erklären?

Delphi-Quellcode:

  TDings = class(TInterfacedObject)
  private
    fBumsList: IGuidList;
    ...
  public
    constructor Create; override;
    destructor Destroy; override;
    ...
  end;


constructor TDings.Create;
var
  tmpBumsList: IGuidList;
begin
  inherited;

  tmpBumsList := TFactory.GetNewGuidList;
  // tmpBumsList.RefCount = 1

  fBumsList := TFactory.GetNewGuidList;
  // fBumsList.RefCount = 2
end;

[himitsu]

Es kann sein, daß der Compiler die Variable tmpBumsList direkt als Result für GetNewGuidList verwendet.
Nein, das ist bestimmt so.

Gemanagete Typen als Result werden in einen Var-Parameter umgewandelt.
Aus

Delphi-Quellcode:

function GetNewGuidList: IGuidList;

macht der Compiler ein

Delphi-Quellcode:

procedure GetNewGuidList(var Result: IGuidList);

.

Da das Feld nicht direkt übergeben werden kann (bzw. er zu doof dafür ist), wird automatisch eine temporäre Variable generiert.

Der Code des Compilers sieht also so aus

Delphi-Quellcode:

constructor TDings.Create;
var
  tmpBumsList: IGuidList;
  {$REGION 'AUTOGENERATED'}
  AutogeneratedVariable1: IGuidList;
  {$ENDREGION}
begin
  {$REGION 'BEGIN'}
  tmpBumsList := nil;
  AutogeneratedVariable1 := nil;
  try
  {$ENDREGION}

  inherited Create;

  TFactory.GetNewGuidList(tmpBumsList);
  // tmpBumsList.RefCount = 1

  TFactory.GetNewGuidList(AutogeneratedVariable1);
  Self.fBumsList := AutogeneratedVariable1;
  // fBumsList.RefCount = 2

  {$REGION 'END'}
  finally
    tmpBumsList := nil;
    AutogeneratedVariable1 := nil;
  end;
  {$ENDREGION}
end;

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1291655)

Ok, danke, so tief war ich da noch nicht eingestiegen (verstehe das auch jetzt nur ansatzweise).

Einfach mal mit Debug dcus durch ein TInterfacedObject.Create mit F7 steppen und schauen.

@Himi
Und wo soll das jetzt nen Memoryleak sein? Temporäre RefCounts sind doch egal.
Am Ende der Methode wird die compilergenerierte implizite Variable gecleart und alles is gut. :)