Meine neuste ARC-Hölle

[Mavarik]

Hallo Zusammen!

Wenn man ein Interface erzeugt und es wieder auf NIL setzt, was erwartet man dann? Richtig, dass der Destructor des Objects aufgerufen wird...

Auf Windows haben wir kein ARC, also was macht der gute App-Programmierer... Richtig keine Object verwenden, sondern unter allen Plattformen nur InterfacedObjects verwenden - das sollte ja überall gleich funktionieren...

Dachte ich...

Anbei ein kleines Testprogramm zum gruseln...

Mavarik

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

[Uwe Raabe]

Zitat:

Wenn man ein Interface erzeugt und es wieder auf NIL setzt, was erwartet man dann? Richtig, dass der Destructor des Objects aufgerufen wird...

Das ist vielleicht etwas zu salopp formuliert. Bei Reference-Counted Instanzen wird der Destructor aufgerufen, wenn der RefCount auf 0 geht. Das kann mit dem expliziten Nil-Setzen einer Interface-Variable einher gehen, muss es aber nicht.

In dem Fall Button1 vermute ich, du spielst auf die verspätete Freigabe an, die erst beim Beenden der Routine erfolgt. Hier kommen drei Dinge zusammen, die zu diesem Verhalten führen:

1. GFoo ist eine globale Variable
2. Das Interface wird durch eine Funktion erzeugt
3. Beide Zuweisungen auf GFoo findet im selben Scope statt

In Punkt 2 erzeugt der Compiler in dieser Konstellation eine versteckte Variable für den Rückgabewert und weist diesen getrennt der globalen Variablen zu. Diese versteckte Variable wird aber eben erst bei Verlassen des Scope auf nil gesetzt.

Was Button2 betrifft, kann ich keine Besonderheit erkennen. Was erwartest du denn dort und was passiert bei dir?

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