Interfaces in lokalen Variablen und deren Freigabe

[swestner]

Hallo,

ich habe folgenden Code:

Code:

procedure TfrmEditBasic.actAddDatapointsExecute(Sender: TObject);
var
  g:IMyInterfacedObject;
  a: TMyObject;
  b: TMyObject1;
begin
  a:=TMyObject.Create;
  b:=TMyObject1.Create;
  g:=TMyInterfacedObject.Create(a, b);  // liefert ein TMyInterfacedObject zurück
  // ...
end;

TMyInterfacedObject fügt die beiden im Konstruktur übergebenen Objekte in eine Liste ein und wenn dann am Ende der Methode das g von Delphi zerstört wird dann zerstört das TMyInterfacedObject automatisch auch die Objekte a und b und ich spare mir das Free am Ende.

Mit FastMM4 erhalte ich beim End eine Schutzverletzung. a oder b werden doppelt freigegeben.

Wenn ich vor dem End ein g:=Nil mache, dann ist die Schutzverletzung weg.

Alternativ habe ich meinen Code wie folgt umgebaut und die lokale Variable weggelassen und dann erhalte ich auch keine Schutzverletzung:

Code:

procedure TfrmEditBasic.actAddDatapointsExecute(Sender: TObject);
var
  a: TMyObject;
  b: TMyObject1;
begin
  a:=TMyObject.Create;
  b:=TMyObject1.Create;
  CreateInterfacedObject(a,b);
  //...
end;

wobei CreateInterfacdObject wie folgt aussieht:

Code:

function CreateInterfacdObject (var v0, v1): IMyInterfacedObject;
begin
  exit(TMyInterfacedObject.Create(v0,v1));
end;

Ich verstehe das gerade absolut nicht. Warum funktioniert der ursprüngliche Code nicht oder nur, wenn ich g auf NIL setze? Und warum funktioniert es wenn ich keine lokale Variable verwende?

Grüße

Stefan

[Der schöne Günther]

Vielleicht ist es für mich noch zu früh am Morgen, aber wenn du das einkürzen könntest sodass ein lauffähiges Programm überbleibt wäre das super hilfreich.

Ich habe es mal versucht in einem kompletten Programm nachzustellen (so wie du es beschrieben hast) und da ist alles in Ordnung - Da scheint also noch mehr dahinter zu stecken.

Delphi-Quellcode:

program Project1;

uses FastMM4, System.SysUtils, System.Generics.Collections;

type
   TMyInterfacedObject = class(TInterfacedObject, IInterface)
   private var
      objects: TObjectList<TObject>;
   public
      constructor Create(const a, b: TObject);
      destructor Destroy(); override;
    end;

{ TMyInterfacedObject }
   constructor TMyInterfacedObject.Create(const a, b: TObject);
   begin
      inherited Create();
      objects := TObjectList<TObject>.Create({ownsObjects:}True);
      objects.Add(a);
      objects.Add(b);
   end;

   destructor TMyInterfacedObject.Destroy();
   begin
      objects.Free();
      inherited;
   end;

procedure p();
var
   a, b: TObject;
   g: IInterface;
begin
   a := TObject.Create();
   b := TObject.Create();
   g := TMyInterfacedObject.Create(a, b);
end;

begin
   p();
end.

Was gibt es denn noch spannendes was bei dir mit

Delphi-Quellcode:

// ...

angedeutet ist?

[jaenicke]

Zitat:

Zitat von swestner (Beitrag 1493840)

Code:

function CreateInterfacdObject (var v0, v1): IMyInterfacedObject;
begin
  exit(TMyInterfacedObject.Create(v0,v1));
end;

Versuch es mal ganz normal mit der Zuweisung an Result...

Delphi-Quellcode:

function CreateInterfacdObject (var v0, v1): IMyInterfacedObject;
begin
  Result := TMyInterfacedObject.Create(v0, v1);
end;

FastMM4 sollte dir auch die Stacktraces liefern. Damit kann man die Ursache meistens gut finden.

[generic]

Zu dem reference counting in Interfaces hab ich ein Video im Kanal:
https://www.youtube.com/watch?v=wrnyJW6dtgY

Wie Jänike schreibt mit "Result:=" gibst du Werte zurück.
Mit "exit" beendest du die aktuelle Funktion und der aktuell Result-Wert wird genutzt.

Das gilt bis Delphi 2009. Danach kann man das Result theoretisch auch im Exit setzen.
https://docwiki.embarcadero.com/Libr...en/System.Exit

Ich kann mir aber vorstellen, dass da vielleicht ein Bug drin ist, welcher die Referenzzählung durcheinander bringt.
Persönlich finde die Jänike Methode allerdings schöner als Exit(<Wert>);

[Blup]

Ein kleiner Test zeigt, dass die Freigabe ordentlich funktioniert:

Delphi-Quellcode:

procedure Test;
var
  a, b, c: TNameObject;
  g: IName;
begin
  a := TNameObject.Create('A');
  b := TNameObject.Create('B');
  c := TNameObject.Create('C');
  g := TTestObject.Create('G', a, b);
  writeln('interface ', g.Name);
end;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    ReportMemoryLeaksOnShutDown := True;
    Test;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Object C wurde absichtlich nicht freigegeben:

Code:

object A create
object B create
object C create
object G create
interface G
object A destroy
object B destroy
object G destroy
Unexpected Memory Leak
An unexpected memory leak has occurred. The unexpected small block leaks are:

1 - 12 bytes: TNameObject x 1
13 - 20 bytes: UnicodeString x 1

Zeig uns doch mal dein TMyInterfacedObject und was du sonst noch so mit A und B anstellst.

[jaenicke]

Zitat:

Zitat von generic (Beitrag 1493847)

Ich kann mir aber vorstellen, dass da vielleicht ein Bug drin ist, welcher die Referenzzählung durcheinander bringt.

Das wäre kein Bug, sondern ein logisches Problem. Erzeugt man eine Instanz über den Konstruktor, erzeugt man eine Objektinstanz. Der Referenzzähler wird erst bei der Übergabe in eine Interfacereferenz erhöht. Packt man die Objektreferenz aber gar nicht in eine Interfacereferenz, sondern übergibt die Instanz direkt an eine konstante Methode, wird der Referenzzähler nirgends erhöht. Denn die aufgerufene Methode kann ja nicht wissen, dass der Referenzzähler dort erhöht werden muss. Denn durch das const wird das eigentlich gespart. Und der Konstruktur kann nicht wissen, dass er den Referenzzähler um eins erhöhen müsste, der hat ja auch gar nichts damit zu tun.

Der Compiler wiederum könnte zwar theoretisch mit Compilermagic ermitteln, dass dieses Problem an der Stelle besteht, und entsprechend den Referenzzähler korrigieren. Allerdings steht dem das Halteproblem entgegen. Der Compiler kann daher nicht zuverlässig feststellen, ob er an einer Stelle den Referenzzähler korrigieren muss oder nicht.

Und deshalb muss man Objektreferenzen stets in einer Variablen speichern um das Problem zu umgehen.

Bei Exit besteht das Problem aber nicht. Hier wird IntfCopy aufgerufen und entsprechend der Referenzzähler erhöht. Die bisherigen Angaben reichen daher nicht um das Problem nachzuvollziehen.

[swestner]

Hallo,

danke für die vielen Rückmeldungen.

Ich konnte das Problem jetzt im Rahmen eines Testprojekt reproduzieren. Das Projekt ist angehängt.

Das Problem ist die Verwendung des Objekts in der anonymen Methode in Verbindung mit dem Interface. Da geht was kaputt...

Code:

unit fMain;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TObjectPtr = ^TObject;

  IMyInterface = interface(IUnknown)
  end;

  TMyInterfacedObject = class(TInterfacedObject, IMyInterface)
  private var
    FObjectPtrs: array [0..0] of TObjectPtr;
  public
    constructor Create(var aObj: TObject);
    destructor Destroy; override;
  end;

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
    procedure TestAnonymProc(aProc: TProc);
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TMyInterfacedObject }
constructor TMyInterfacedObject.Create(var aObj: TObject);
begin
  FObjectPtrs[0] := @TObject( aObj );
  TObject( aObj ) := nil;
end;

destructor TMyInterfacedObject.Destroy;
begin
  if Assigned( FObjectPtrs[0]^) then
  begin
    FObjectPtrs[0]^.Free;     // <== AV
    FObjectPtrs[0]^ := nil;
  end;
  inherited;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  intf: IMyInterface;
  list: TStringList;
begin
  intf := TMyInterfacedObject.Create( TObject(list) );
  list := TStringList.Create;

  list.Add( 'Item1' );

  TestAnonymProc(
    procedure
    begin
      list.Add( 'Item2' )
    end
  );
  list.Add( 'Item3' );
end;

procedure TForm1.TestAnonymProc(aProc: TProc);
begin
  aProc();
end;

end.

Jetzt stellt sich die Frage: warum?

Grüße

Stefan

[Der schöne Günther]

Warum tust du dir das mit den Zeigern an?
Nimm eine TObjectList und gut ist - Du musst dich noch nicht einmal um die Freigabe der enthaltenen Objekte kümmern.

Siehe mein Beispiel im 2. Beitrag.

[swestner]

Wenn ich die TObjectList nehme löst das nicht das Problem, daß durch die anonyme Methode was kaputt geht....

[jaenicke]

Bei mir (aktuelle Community Edition) passiert kein Fehler.

Den Sinn der Pointer sehe ich aber auch nicht.

[Der schöne Günther]

Ich verstehe das überhaupt nicht, ich bin allerdings auch nicht so schlau.

Weshalb gibt man eine nicht initialisierte Referenz als var-Parameter in den Konstruktor, speichert sich den und drückt dann dort ein nil rein?

Du siehst doch schon in deinem Destruktor von TMyInterfacedObject dass da Schrott drinsteht und versuchst den dann freizugeben.

Das ist allerdings tatsächlich nur der Fall wenn die anonyme Methode im Spiel ist.

Die anonyme Methode "captured" deine lokale Variable "list". Die wandert dann irgendwie anderswo auf den Heap und der komische Trick mit den Zeigeradressen scheint nicht mehr zu funktionieren. Auch für den blöden Debugger ist die lokale Variable "list" unsichtbar.

[jaenicke]

Stimmt, da hast du Recht. Ich habe es nur laufen lassen und gar nicht genauer angeschaut. Die beiden Zeilen machen in der Reihenfolge natürlich keinen Sinn:

Delphi-Quellcode:

  intf := TMyInterfacedObject.Create( TObject(list) );
  list := TStringList.Create;

Richtig wäre:

Delphi-Quellcode:

  list := TStringList.Create;
  intf := TMyInterfacedObject.Create( TObject(list) );

Ach ja... hier gibt es übrigens eine bessere Lösung für dieses Problem:
https://blog.grijjy.com/2020/08/12/c...mart-pointers/

Denn die Herangehensweise aus dem obigen Beispielprojekt macht wenig Sinn, da man so z.B. bei asynchron ausgeführten anonymen Methoden Fehler bekommt, weil das Interface eigentlich gar nichts mit dem Objekt zu tun hat. Dann ist es sinnvoller das Objekt direkt freizugeben...

[Uwe Raabe]

gelöscht

[swestner]

@jaenicke:
Ich denke, das Ganze macht doch Sinn...

Ziel des ganzen Konstrukts ist, daß ich nicht in jeder Methode alle dynamisch angelegten Variablen mit try..finally absichern muß.

Die Variable wird im VAR-Teil deklariert und dann der Pointer auf diese Variable in dem InterfaceObject gespeichert. Dabei spielt es keine Rolle, ob in der Variable schon was drin steht (Objekt) oder nicht.

Später wird dann der Variable ein Objekt zugewiesen.

Wenn die Methode verlassen wird, wird das Interface zerstört und dann werden im Destruktor alle Objekte in den lokalen Variablen zerstört.

Das funktioniert in unserem Programmcode tausende Mal so.

Haben wir übrigens nicht selbst erfunden sondern BoldSoft / Borland schon 2004.

Jetzt die Frage:
Kann das nach dem gleichen Prinzip 2021 besser realisiert werden?
Warum macht die anonyme Methode das "System" kaputt?

Stefan

[Uwe Raabe]

Durch die Verwendung von list in der Anonymen Methode wird die Instanz von list durch das Variable Binding intern verschoben und die in FObjectPtrs gespeicherte Referenz enthält ab dann ungültige Daten.

Man kann das schön im Debugger sehen: Außerhalb von TestAnonymProc kann er list nicht auflösen, innerhalb schon.

[jaenicke]

Zitat:

Zitat von swestner (Beitrag 1493913)

@jaenicke:
Ich denke, das Ganze macht doch Sinn...

Ziel des ganzen Konstrukts ist, daß ich nicht in jeder Methode alle dynamisch angelegten Variablen mit try..finally absichern muß.

Ja, schon, aber wozu die Pointer? Eine Objektreferenz ist doch per se schon ein Pointer. Ein Pointer auf einen Pointer macht an der Stelle keinen Sinn.

Zitat:

Zitat von swestner (Beitrag 1493913)

Kann das nach dem gleichen Prinzip 2021 besser realisiert werden?

Ja, so wie ich es verlinkt habe. Smart Pointers ist das Stichwort. Die machen genau das, nur deutlich sinnvoller.