Den Leak bei rekursiven Closures bekämpfen

[Mavarik]

Zitat von Uwe Raabe:

Zitat von Mavarik:

                   IPrinter := NIL;

Frank! Aufwachen!

Ja ja

                   myPrinter := NIL;

[Der schöne Günther]

Das mit dem IPrinter sollte nur verdeutlichen dass wir es u.U. nicht nur mit ein paar Byte für die Closure sondern evtl. mit richtig dicken Brocken zu tun haben

Ich bedanke mich noch einmal ganz herzlich bei allen

Ich hatte gestern wohl einen schlechten Tag und irgendwie übersehen dass das explizite "Nil-Setzen" der Variable Abhilfe schafft.


Da ich keinen Assembler verstehe musste ich es zwar zwei, drei mal lesen, aber ich glaube ich habe es jetzt verstanden. Dieses implizit erstellte "Etwas" scheint demnach die Closure nur als Zeiger zu referenzieren oder weshalb ruft er kein IntfClear darauf auf wenn er selber platt gemacht wird? Vielleicht sollte man das ändern?

[Stevie]

Zitat von Der schöne Günther:

Dieses implizit erstellte "Etwas" scheint demnach die Closure nur als Zeiger zu referenzieren oder weshalb ruft er kein IntfClear darauf auf wenn er selber platt gemacht wird? Vielleicht sollte man das ändern?

Weil gecapturte Variablen Felder der durch den Compiler generierten Klasse hinter der anonymen Methode sind und keine lokale auf dem Stack liegenden Variablen.
Das ist übrigens auch der Grund, warum man die nicht mehr mit dem Debugger anschauen kann - dem wurde das nämlich scheinbar niemals beigebracht.
Innerhalb der anonymen Methode allerdings kann man sie sehen und dort sieht man auch, dass es sich um ein Objekt handelt:



Dementsprechend werden diese Felder auch niemals beim end einer Methode angefasst/finalized. Denn die anonyme Methode könnte ja noch weiter leben.
Um das festzustellen, müsste der Compiler eine eher komplexe Analyse des Codes durchführen. Eventuell wäre das aber etwas, was man Roman für FixInsight mal vorschlagen könnte.