MemoryLeak bei TList<IMyInterface>

[himitsu]

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

Mist, ich hätte noch eine Minute warten müssen, dann hätte ich die 10101 ergatterst. (jetzt muß ich noch einen Monat warten, bis zur 1010101 )
https://quality.embarcadero.com/browse/RSP-10100

Wie sieht das beim ARC aus? Müsste ja eigentlich gleich sein.

[Uwe Raabe]

Zitat von himitsu:

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

Naja, Fehler ist vielleicht etwas übertrieben. Immerhin setzt der Programmierer ja durch das const ganz bewusst die Referenzzählung außer Kraft. Man muss halt wissen was man tut. Wir sind hier ja schließlich nicht im Java-Forum.

Du schreibst ja auch selbst, daß der Compiler eine Warnung ausgeben soll, die man dann ja selbst zu einen Fehler aufwerten kann, wenn man das möchte. Und eine fehlende Warnung ist vielleicht unschön, aber für den Fehler ist man schon selbst verantwortlich und nicht der Compiler - der kann ja dort nun mal nicht anders. Das Konstrukt ist syntaktisch und semantisch korrekt, tut sogar das was es soll, führt nur leider zu einem Memoryleak. Das täte ein fehlendes Free bei jeder anderen Objektinstanz aber auch und dort gibt es auch keine Warnung vom Compiler (allerdings von anderen Tools).

[himitsu]

Der Compiler könnte eine Temp-Variable erstellen und diese an den Parameter übergeben.

Gut, daß macht der Compiler bestimmt, aber ich wette das ist eine Objekt-Variable, die hier ja nicht referenzgezählt sind.

[edit] Dann könnte es im ARC doch funktionieren, aber dann müssten wie auch noch prüfen, ob das bei allen Objekten, auch aus Objektvariablen, bei Übergabe an Const-Interface-Parameter knallt.

[Memnarch]

Wie bereits im Ticket erwähnt, hat dies nichts mit dem direkten übergeben von erstellten Objekten zu tun. Dieses verhalten bekommt ihr bei impliziten casts von Objectinstanzen auf Interface bei Parametern.

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