MemoryLeak bei TList<IMyInterface>

[Stevie]

Zitat von himitsu:

Wir haben somit einen mindestens 20 Jahre alten "schweren" Fehler entdeckt.

Entdeckt? Pff, der Fehler is fast so lang bekannt, wie er existiert - gratulation zum x-ten Duplicate Report diesbezüglich.

Gab erst vor nicht allzu langer Zeit dazu eine Diskussion (und Ausreden, warums nich gemacht wird)

Sehr lustig auch der "Closed" Kommentar zu dem von mir verlinkten Ticket:
"Works as expected.
Should not pass const interface parameter to non-const parameter."

What the f...?

Am besten einfach drauf sch...verzichten, dass sie es jemals fixen und hier nen upvote geben:
http://fixinsight.userecho.com/topic...e-same-object/

[himitsu]

Im neuen QC ist er noch nicht doppelt.

[stahli]

generell:

Der Fehler ist ganz sicher als ein solcher zu bezeichnen.
Über das Problem wird wohl jeder stolpern, der Interfaces in Delphi benutzt. Ein logisches und zu erwartendes Verhalten ist das jedenfalls nicht.
Es ist für mich nicht nachvollziehbar, dass Emba das nicht in Ordnung bringt (ggf. mit einem Projektschalter: InterfaceMemoryLeakProblemBeibehalten = True).


mein Problem:

... konnte ich damit aber noch nicht bereinigen. Muss ich heute Abend mal weiter graben.
Ich erzeuge über eine Factory Objekte und verwalte die Schnittstellen in verschiedenen Listen. An einer Stelle stelle funktioniert das irgendwie nicht richtig (entweder gibt es MemoryLeaks oder Zugriffsverletzungen) und ich konnte den Fehler bisher trotz der oben Hinweise noch nicht finden.


eine andere Frage noch:

In den überwachten Ausdrücken kann ich ja MyObject.RefCount einsehen.
Wenn ich aber nur eine Schnittstelle IMyInterface habe geht das nicht.
Ein casten (MyInterface as TMyClass).RefCount funktioniert auch nicht.
Wie kann ich den RefCount eines Interfaces (oder des Objektes hinter einem Interface) einsehen?

[himitsu]

AS kann in den überwachten Ausdrücken nicht verwendet werden,
auch solltest du Seiteneffekte erlauben.

• Entweder du baust dir ins Interface eine GetRefCount-Methode ein
• oder du baust dir eine Funktion, welche das Interface als CONST entgegennimmt, RefCount zurückgibt und rufst diese Funktion in den Ausdrücken auf.

[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).