MemoryLeak bei TList<IMyInterface>

[stahli]

Ok, danke für die Idee.

Ich dachte eigentlich, dass ich mich als NixBlicker oute.
Dass die IDE das wirklich nicht anzeigt ist echt schwach.
Das braucht doch eigentlich jeder, der intensiver mit Interfaces arbeitet...

[himitsu]

"intensiv" ist gut, ich wollte eine gemeinsame Funktion (speicherverwaltung für sich gegenseitig referenzierende Interfacelisten) in einem generischen Interface+Klasse umsetzen, aber kurz vorm Ende, bin ich mal wieder an die Grenzen der Generics gestoßen.

[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 von stahli:

Hmm, offenbar sind gegenseitige Referenzen mein Problem.

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

Zitat:

Warum sind denn _AddRef und _Release nicht virtuell

Das hab ich mich auch schon gefragt.

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.

[Der schöne Günther]

Zitat von stahli:

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 IFDEF DEBUG doch virtuell zu haben?

[Stevie]

Zitat von stahli:

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 von stahli:

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

procedure TInterfacedObject.AfterConstruction;