Meine neuste ARC-Hölle

[Stevie]

Zirkuläre Referenz - der Aufruf von FInvoke in der anonymen Methode in TFDKMessageHandler captured Self implizit und sorgt unter ARC somit für ein __ObjAddRef -> memory leak

Ist schon länger bekannt, dass anonyme Methoden unter ARC schnell mal Leaks erzeugen - https://quality.embarcadero.com/browse/RSP-10176

Was wir in Spring4D typischerweise an solchen Stellen machen, ist folgendes:

Delphi-Quellcode:

constructor TFDKMessageHandler<TMSG>.Create(AInvoke: TMyMSGType);
{$IFDEF AUTOREFCOUNT}
var
  capturedSelf: Pointer; // alternativ mit [unsafe] dann spart man sich den hardcast weiter unten, aber da gabs in früheren Versionen noch Probleme, daher stumpf mit Pointer
{$ENDIF}
begin
  inherited Create;
  FInvoke := AInvoke;

{$IFDEF AUTOREFCOUNT}
  capturedSelf := Self;
{$ENDIF}

  FID := TMessageManager.DefaultManager.SubscribeToMessage(TFDKMSGType<TMSG>,Procedure (Const Sender : TObject;Const M : TMessage)
           begin
           {$IFDEF AUTOREFCOUNT}with TFDKMessageHandler<TMSG>(capturedSelf) do{$ENDIF}
             FInvoke(Sender,TMSG(TFDKMSGType<TMSG>(M).Value));
           end);
end;

[Uwe Raabe]

Zitat von Stevie:

Zirkuläre Referenz

Wäre ja auch wirklich kein Luxus gewesen, das erwartete und tatsächliche Verhalten mal eben zu beschreiben.

[Stevie]

Zitat von Uwe Raabe:

Zitat von Stevie:

Zirkuläre Referenz

Wäre ja auch wirklich kein Luxus gewesen, das erwartete und tatsächliche Verhalten mal eben zu beschreiben.

Ich dachte, das wüsstest du von der anderen Stelle, wo Frank das heute schon gepostet hat

[Uwe Raabe]

Zitat von Stevie:

Ich dachte, das wüsstest du von der anderen Stelle, wo Frank das heute schon gepostet hat

Da kann aber nun mal nicht jeder reinschauen und wir beide (und vielleicht noch eine Handvoll andere) sind hier wohl auch nicht die Zielgruppe gewesen, oder?

[Mavarik]

Zitat von Daniel:

Mit einem Beitrag wie diesem erzeugst Du eigentlich nur Unsicherheit und Halbwissen auf allen Seiten. Hast Du analysiert, an welcher Stelle das von Dir beobachtete Verhalten vom erwarteten Verhalten abweicht? Oder ist es genau das, was Du im Rahmen dieser Diskussion herausfinden möchtest?

Nun ja, sagen wir mal so... Ich versuche seit zwei Wochen die "letzten" Fehler aus meiner App zu bekommen, stoße aber leider immer wieder auf Probleme, die sich nicht eindeutig Identifizieren lassen.

Hierbei gehe ich immer erstmal davon aus:
1. Der Fehler liegt bei mir
2. Der Fehler liegt an der aktuellen Delphi-Version
3. Es ist ein genereller Fehler

Und dann stellt sich immer die Frage QC oder nicht...

Daher tausche ich mich "gerne" vorher mit dem ein oder anderen aus.

Zitat von Uwe Raabe:

Wäre ja auch wirklich kein Luxus gewesen, das erwartete und tatsächliche Verhalten mal eben zu beschreiben.

Da gebe ich Dir recht... Wollte eigentlich mehr schreiben, aber dann ging das Telefon - Du kennst das sicherlich auch...

Zitat von Stevie:

Ist schon länger bekannt, dass anonyme Methoden unter ARC schnell mal Leaks erzeugen - https://quality.embarcadero.com/browse/RSP-10176

Danke für Deine Hilfe (überall )

Mein kleines Testprogramm - abgesehen von den Erklärungen von Uwe und Stefan, die natürlich richtig sind - zeigt aber sicherlich auf, dass sich das Verhalten unter ARC nicht immer so offensichtlich zeigt, wir man es erwartet.

Mavarik

[himitsu]

Und jetzt versuch mal so ein DOM hinzubekommen, dass unter ARC und NichtARC funktioniert und wo es massig Kreisreferenzen gibt, ohne ein Speicherleck.

Parent kennt Kinder und Kinder kennen Parent und Root.



Und das ohne böse Casts, um die Referenzählung des ARC zu umgehen
und so, dass der Code deiner Componente auch mit etwas älteren Delphis noch kompatibel ist,
und ohne dass der halbe Code nur noch aus IFDEFS besteht.

[WeakRef] kann/konnte man nicht verwenden, da es das unter Windows nicht gibt/gab.
Und [NoRef] vermisse ich sowieso.

[Stevie]

Hier nochmal ein Minimalbeispiel (ich mach beim ARC Zeugs testen seit 10.2 immer gern Programme die ich kurz auf meine Ubuntu VM feuern kann, daher ohne FMX)

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

uses
  System.SysUtils;

type
  TTest = class(TInterfacedObject)
  private
    fProc: TProc;
    procedure Something;
  public
    constructor Create;
    destructor Destroy; override;
  end;

var
  destroyCalled: Boolean;

{ TTest }

constructor TTest.Create;
begin
  fProc := Something;
(*
  actually compiled into

  fProc :=
    procedure begin
    begin
      Self.Something; // <- causes Self to be captured
      // all captured fields are strong references and thus TTest keeps itself alife
      // with the circular reference: fProc <-> Self
    end;
    *)
end;

destructor TTest.Destroy;
begin
  destroyCalled := True;
  inherited;
end;

procedure TTest.Something;
begin
end;

procedure Main;
var
  intf: IInterface;
begin
  intf := TTest.Create;
  intf := nil;
  Assert(destroyCalled);
end;

begin
  Main;
end.

Da anonyme Methoden immer mehr Einzug halten (auch im offiziellen Delphi Code) halte ich diesen Defekt schon für äußerst
kritisch (ja, man kann drumherum arbeiten) gerade da er schon einiges an Wissen über die Interna vorraussetzt.

Also bitte fleißig voten sofern möglich

Zitat von himitsu:

Und jetzt versuch mal so ein DOM hinzubekommen, dass unter ARC und NichtARC funktioniert und wo es massig Kreisreferenzen gibt, ohne ein Speicherleck.

Siehe FMX und FireDAC :grusel:

[himitsu]

Zitat:

intf := nil;

Wenn du statt an ARC (Automatic Reference Counting) an das in meiner Signatur denkst (Garbage Collector),
dann hieße es "ich brauch dich nicht mehr ... kannst du böser SpeicherManager also irgndwann wegwerfen".

[Stevie]

Zitat von himitsu:

Wenn du statt an ARC (Automatic Reference Counting) an das in meiner Signatur denkst (Garbage Collector),
dann hieße es "ich brauch dich nicht mehr ... kannst du also also irgndwann wegwerfen".

Nein, es heißt: "Diese Variable zeigt nicht mehr auf dich, wenn sonst auch keiner mehr auf dich zeigt, dann ..."

[himitsu]

"... dann braucht dich keiner mehr"

Aber das heißt noch lange nicht, dass man es auch sofort das Freigeben muß. (aktuell im ARC ja, aber wer weiß was kommt)
Es könnte auch erstmal nur als Frei markiert werden und später kümmert sich in Ruhe jemand ums Aufräumen .... so ist das Programm gleich viel schneller und braucht nur ein bissl mehr Speicher.

Wenn du den alten Kühlschrank nicht mehr brauchst, dann trägst du ihn doch auch nicht sofort zum Wertstoffhof?