Den Leak bei rekursiven Closures bekämpfen

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