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

Delphi-Quellcode:

TPrinter

-Instanz und eine

Delphi-Quellcode:

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

Delphi-Quellcode:

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 8-)

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


PS: Wie konntest du nur die Implementation von TPrinter erraten :-D

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

Zitat von Der schöne Günther (Beitrag 1342105)

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

Delphi-Quellcode:

TPrinter

-Instanz und eine

Delphi-Quellcode:

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

Delphi-Quellcode:

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:

Zitat von Mavarik (Beitrag 1342138)

Delphi-Quellcode:

                   IPrinter := NIL;

Frank! Aufwachen! :hello:

[Der schöne Günther]

Zitat:

Zitat von Mavarik (Beitrag 1342138)

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)

[Stevie]

Das mit dem IPrinter ist komplett irrelevant für das Beispiel, hier ist der minimale Testcase:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  FastMM4,
  SysUtils;

procedure Main;
var
  p: TProc;
  count: Integer;
begin
  p :=
    procedure
    begin
      inc(count);
      if count < 3 then
        p();
    end;
  p();
  Writeln((IInterface((@p)^) as TInterfacedObject).RefCount);
  p := nil;
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  Main;
  Readln;
end.

Wie man sehen kann, ist der RefCount von p auf 2. Das ist aber nicht etwa der Fall, weil p sich selbst captured,
sondern weil der Compiler hier eine implizite interface Variable für die anonyme Methode anlegt.
Das kann man sehen, wenn man sich den Prolog der Prozedur anschaut, der wie folgt aussieht:

Code:

Project1.dpr.13: begin
00411E70 55               push ebp
00411E71 8BEC             mov ebp,esp
00411E73 83C4F8           add esp,-$08
00411E76 33C0             xor eax,eax
00411E78 8945F8           mov [ebp-$08],eax
00411E7B 33C0             xor eax,eax
00411E7D 55               push ebp
00411E7E 68151F4100       push $00411f15
00411E83 64FF30           push dword ptr fs:[eax]
00411E86 648920           mov fs:[eax],esp
00411E89 B201             mov dl,$01
00411E8B A17C1D4100       mov eax,[$00411d7c]
00411E90 E85730FFFF       call TObject.Create
00411E95 8945FC           mov [ebp-$04],eax
00411E98 8D45F8           lea eax,[ebp-$08]
00411E9B 8B55FC           mov edx,[ebp-$04]
00411E9E 85D2             test edx,edx
00411EA0 7403             jz $00411ea5
00411EA2 83EAF8           sub edx,-$08
00411EA5 E82267FFFF       call @IntfCopy

Und dann die zuweisung auf p:

Code:

Project1.dpr.14: p :=
00411EAA 8B45FC           mov eax,[ebp-$04]
00411EAD 83C00C           add eax,$0c
00411EB0 8B55FC           mov edx,[ebp-$04]
00411EB3 85D2             test edx,edx
00411EB5 7403             jz $00411eba
00411EB7 83EAEC           sub edx,-$14
00411EBA E80D67FFFF       call @IntfCopy

Woher kommt also das Leak?
Schauen wir uns den Epilog der Prozedur an - hier mit Rekursion:

Code:

Project1.dpr.24: end;
00411EFF 33C0             xor eax,eax
00411F01 5A               pop edx
00411F02 59               pop ecx
00411F03 59               pop ecx
00411F04 648910           mov fs:[eax],edx
00411F07 681C1F4100       push $00411f1c
00411F0C 8D45F8           lea eax,[ebp-$08]
00411F0F E8A066FFFF       call @IntfClear
00411F14 C3               ret 
00411F15 E94638FFFF       jmp @HandleFinally
00411F1A EBF0             jmp $00411f0c
00411F1C 59               pop ecx
00411F1D 59               pop ecx
00411F1E 5D               pop ebp
00411F1F C3               ret

Einmal IntfClear, das ist für die vom Compiler im Prolog implizit angelegte Variable. Aber wo ist das IntfClear für p?
Dazu muss man wissen, wie das capturen von Variablen vom Compiler behandelt wird. Diese befindet sich nämlich nun als Feld in
dem vom Compiler gebauten Objekt für die anonyme Methode und wird somit nicht mehr als lokale Variable behandelt (die sonst hier auch gecleared würde).

Schauen wir uns mal den Epilog ohne Rekursion an (der aufruf von p innerhalb von p auskommentiert):

Code:

Project1.dpr.24: end;
00411E99 33C0             xor eax,eax
00411E9B 5A               pop edx
00411E9C 59               pop ecx
00411E9D 59               pop ecx
00411E9E 648910           mov fs:[eax],edx
00411EA1 68BE1E4100       push $00411ebe
00411EA6 8D45F4           lea eax,[ebp-$0c]
00411EA9 E80667FFFF       call @IntfClear
00411EAE 8D45FC           lea eax,[ebp-$04]
00411EB1 E8FE66FFFF       call @IntfClear
00411EB6 C3               ret 
00411EB7 E9A438FFFF       jmp @HandleFinally
00411EBC EBE8             jmp $00411ea6
00411EBE 8BE5             mov esp,ebp
00411EC0 5D               pop ebp
00411EC1 C3               ret 
00411EC2 8BC0             mov eax,eax

Siehe da, 2mal IntfClear, einmal für p und das zweite mal für die vom Compiler generierte Variable. Das führt dann zum Freigeben der Instanz.