MemoryLeak bei TList<IMyInterface>

[stahli]

Es gibt im Projekt einige Querverbindungen.
Aber wenn ich das List.Add mal rausnehme passt offenbar alles.

Ich werde das heute Abend mal weiter untersuchen. Gestern bin ich daran etwas verzeifelt.

Hätte ja sein können, dass da ein Bug bekannt wäre oder ich einen generellen Denkfehler hätte.

[Sir Rufo]

Mit diesen Querverbindungen hat es aber nichts zu tun.

Ursache ist einzig und allein, das hier foo( TFoo.Create ); . Dabei wird nämlich kein RefCount erhöht!

[stahli]

@Sir

Ich hatte vorhin keinen roten Kasten...

Heißt das, wenn ich Interface-Parameter in einer Methode nicht benutzt wird gibt es ein MemoryLeak?
Das wäre ja eine sehr unschöne Sache.

Nach meiner derzeitigen Einschätzung dürfte das aber nicht das vorliegende Problem sein, da ich das Speicherleck vermeiden kann, indem ich die Anseisung List.Add(aInterface) auskommentiere.

Mir fällt zwar gerade ein, dass ich wohl List.Add(MyObject) hinzufüge, aber das müsste ja problemlos dennoch das Interface verwalten.
Oder wäre es besser, in einem solchen Fall explizit zu casten: List.Add(MyObject as IMyInterface)? Oder sollte man sogar unbedingt eine temporäre Interface-Variable anlagen und verwenden?


PS: Dein eben nachgeschobenes Construkt verwende ich definiv nicht. Mal sehen, genaueres dann heute Abend...

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

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