Den Leak bei rekursiven Closures bekämpfen

[Der schöne Günther]

Zum Abend noch etwas eher Esoterisches:

Ein schlauer Kerl hatte hier nie die Speicherleck-Prüfung an. Ich schalte sie ein und
sehe dass dieses Konstrukt hier jedes mal eine TPrinter -Instanz und eine myClosure -Methode leaked. Letztere ist rekursiv und erhöht somit ihren eigenen Referenzzähler. Sie selbst hat aber natürlich auch eine Referenz auf den IPrinter weshalb dieser ebenfalls nie tot geht.

Zumindest vermute ich das, denn ich kenne keinen Weg im Debugger die Closure oder von dieser gecapturte Variablen zu untersuchen.
Dafür spricht auch wenn ich, wohl durch die Rekursion, den Referenzzähler der anonymen Methode von Hand um eins verringere- Das ist die letzte (auskommentierte) Zeile.

Delphi-Quellcode:

type
   IPrinter = interface
      procedure write(const value: Integer);
   end;

   TPrinter = class(TInterfacedObject, IPrinter)
      public procedure write(const value: Integer);
   end;

procedure p();
var
   myClosure: TProc;
   myCounter: Integer;
   myPrinter: IPrinter;
begin
   myCounter := 10;
   myPrinter := TPrinter.Create();

   myClosure :=
      procedure()
      begin
         myPrinter.write(myCounter);
         Dec(myCounter);
         if (myCounter > 0) then myClosure();
      end;
   myClosure();

   //IInterface( Pointer(@myClosure)^ )._Release();
end;

Meine Frage: Kann man das so machen? Sollte der Compiler das eines Tages ändern und den Referenzzähler bei Rekursion nicht erhöhen fliegt mir das ja wohl zur Laufzeit um die Ohren.

Das Beispiel ist natürlich stark simplifiziert und wirkt wahrscheinlich übertrieben aufwändig. Und ja, das bekommt man auch ganz klassisch ohne anonyme Methoden hin: Das ist jetzt meine Übergangslösung

[ISurf]

Hallo,
ich hab den Code aus Interesse mal in eine Konsolenanwendung gepackt, aber mit ReportMemoryLeaksOnShutdown auf True zeigt er bei mir keine Leaks an, erst wenn ich myPrinter als TPrinter deklariere, was ja auch Sinn macht.
Version: Delphi 10 Seattle.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
   IPrinter = interface
      procedure write(const value: Integer);
   end;

   TPrinter = class(TInterfacedObject, IPrinter)
      public procedure write(const value: Integer);
   end;

procedure TPrinter.write(const value: Integer);
begin
  System.Write('Wert: ');
  System.Writeln(value);
end;

procedure p();
var
   myClosure: TProc;
   myCounter: Integer;
   myPrinter: IPrinter;
begin
   myCounter := 10;
   myPrinter := TPrinter.Create();

   myClosure :=
      procedure()
      begin
         myPrinter.write(myCounter);
         Dec(myCounter);
         if (myCounter > 0) then myClosure();
      end;
   myClosure();
end;

begin
  ReportMemoryLeaksOnShutdown:=true;
  p();
  Readln;
end.

[Der schöne Günther]

Tut mir leid, ich habe nicht erwähnt dass es nicht beim Delphis mitgeliefertem Memory-Manager sondern erst beim "vollen" FastMM zum Tragen kommt. Und man dementsprechend noch FastMM4.pas als erste Unit in die uses der .DPR aufnehmen muss. Sorry.

Da der "volle" FastMM auch genauso viele Leaks findet wie oft p() aufgerufen wurde denke ich dass die Leaks wirklich da sind. Zur Sicherheit rufe ich p() morgen ein paar Milliarden mal auf und schaue auf den Speicherverbrauch


PS: Wie konntest du nur die Implementation von TPrinter erraten

[ISurf]

Okay damit findet Delphi die Memory Leaks.
Das Ganze scheint sogar zu passieren, wenn man zwei anonyme Methoden in derselben Methode deklariert und sie sich untereinander aufrufen, siehe
http://stackoverflow.com/questions/6...onymous-method

Ich hab testweise eine der Lösungen ausprobiert (nach dem Aufruf myClosure:=nil setzen) und damit entstehen die Leaks nicht mehr.
Eine bessere Lösung scheint es für einen solchen rekursiven Aufruf nicht zu geben.

Gruß,
Simon

[Der schöne Günther]

Ich ... Ich war mir sicher dass ich das "Auf nil setzen" als erstes probiert hatte und es keine Abhilfe brachte. Hier in diesem Beispiel tut es das aber einwandfrei. Tolle Sache, vielen Dank!

Ich probiere morgen noch einmal mein Echtwelt-Beispiel aus, ob es da auch hilft.

[jaenicke]

Nicht immer lässt sich das lösen. Wir haben daher einige Stellen mit RegisterExpectedMemoryLeak registriert, so dass diese in der Statistik nicht mehr auftauchen. Wir haben das dabei immer so implementiert, dass diese registrierten Leaks nicht während der Programmlaufzeit zunehmen, sondern lediglich einmal auftauchen. Deshalb können wir diese problemlos ignorieren.

Wenn natürlich dort dann noch Instanzen von Interfaces drinhängen, wird es komplizierter...

[Mavarik]

Zitat von Der schöne Günther:

Zum Abend noch etwas eher Esoterisches:

Ein schlauer Kerl hatte hier nie die Speicherleck-Prüfung an. Ich schalte sie ein und
sehe dass dieses Konstrukt hier jedes mal eine TPrinter -Instanz und eine myClosure -Methode leaked. Letztere ist rekursiv und erhöht somit ihren eigenen Referenzzähler. Sie selbst hat aber natürlich auch eine Referenz auf den IPrinter weshalb dieser ebenfalls nie tot geht.

Ist nicht eher die IPrinter Referenz das Problem?

Wie wäre es mit:

Delphi-Quellcode:

procedure p();
var
  myClosure: TProc;
  myCounter: Integer;
  myPrinter: IPrinter;
begin
  myCounter := 10;
  myPrinter := TPrinter.Create();

  myClosure := procedure()
                 begin
                   myPrinter.write(myCounter);
                   Dec(myCounter);

                   if (myCounter > 0) then myClosure();

                   myPrinter := NIL;
                 end;
  myClosure();
end;

Mavarik

PS.: OT:Voll die Seuche, wer verwendet den Tabs im Source...

[Uwe Raabe]

Zitat von Mavarik:

                   IPrinter := NIL;

Frank! Aufwachen!

[Mavarik]

Zitat von Uwe Raabe:

Zitat von Mavarik:

                   IPrinter := NIL;

Frank! Aufwachen!

Ja ja

                   myPrinter := NIL;

[Der schöne Günther]

Zitat von Mavarik:

OT:Voll die Seuche, wer verwendet den Tabs im Source...

Ich bin halt Energiesparer.

Zitat:

Let's assume a cost of 7kWh to move 1Gb . That means the cost of using spaces over tabs (assuming 4 spaces per tab; ignoring dictionary compression techniques) is approximately 1.95E-8 kWh per indent, per read. [...] Thus we can see that the energy cost of using spaces instead of tabs adds up to 16,380kWh per day. That's the equivalent of 409 additional cars on the roads.

(Quelle)