MemoryLeak bei TList<IMyInterface>

[Sir Rufo]

Es heisst ganz einfach:

Wenn ich eine Instanz erzeuge und das direkt als ein Argument/Parameter übergebe, dann springt der Referenzzähler nicht an.

Delphi-Quellcode:

IFoo = interface
  procedure Bar;
end;

procedure foo( aFoo : IFoo );
begin
  aFoo.Bar;
end;

var
  LFoo : IInterface;
  LFooObj : TFoo;

foo( TFoo.Create ); // aufpassen, hier kann es zu einem Leak kommen

LFoo := TFoo.Create;
foo( LFoo ); // alles in Butter

LFooObj := TFoo.Create;
foo( LFooObj ); // aufpassen, hier wird auch keine Referenz erhöht!

[himitsu]

Das ist dann aber ein Bug?


Hier procedure foo( aFoo : IFoo ); muß die Referenzzählung hoch gehn

und hier procedure foo( const aFoo : IFoo ); natürlich nicht.

Innerhalb der letzten Methode hat man dann viel Spaß, sobald der Zähler das erste Mal wieder auf 0 fällt.
Und ohne referenzzählenden Zugriff, auf den Parameter, gibt es ein schönes Speicherleck.

[Sir Rufo]

@himitsu

Stimmt ... das const ist der Üpeltäter

Delphi-Quellcode:

program dp_184063;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils;

type
  IFoo = interface
    ['{FEF0782C-9F48-4060-A79D-8697F8431718}']
    procedure Bar;
  end;

  TFoo = class( TInterfacedObject, IFoo )
  private
    FName: string;
  public
    constructor Create( const Name: string );
    destructor Destroy; override;

    procedure Bar;
  end;

  { TFoo }

constructor TFoo.Create( const Name: string );
begin
  inherited Create;
  FName := Name;
  WriteLn( 'TFoo(', FName, ').Create' );
end;

destructor TFoo.Destroy;
begin
  WriteLn( 'TFoo(', FName, ').Destroy' );
  inherited;
end;

procedure TFoo.Bar;
begin
  WriteLn( 'TFoo(', FName, ').Bar' );
end;

procedure CallConstFoo( const aFoo: IFoo );
begin
  aFoo.Bar;
end;

procedure CallFoo( aFoo: IFoo );
begin
  aFoo.Bar;
end;

procedure Test;
begin
  CallConstFoo( TFoo.Create( 'ConstFoo' ) );
  CallFoo( TFoo.Create( 'Foo' ) );
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  try
    Test;
  except
    on E: Exception do
      WriteLn( E.ClassName, ': ', E.Message );
  end;
  ReadLn;

end.

ergibt bis zum abschließenden ReadLn

Code:

TFoo(ConstFoo).Create
TFoo(ConstFoo).Bar
TFoo(Foo).Create
TFoo(Foo).Bar
TFoo(Foo).Destroy

und somit einen MemLeak für die ConstFoo benannte Instanz

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