Array korrekt freigeben

[QuickAndDirty]

Zitat von Uwe Raabe:

Delphi-Quellcode:

  { aber hier ist eine Finalisierung für MyPtr^ notwendig, andernfalls bleibt der string bestehen }
//  Finalize(MyPtr^);

Holy shit.
Ich habe nie New+Dispose benutzt. Und ich dachte immer longstrings kümmern sich selbst um sich und da muss ich mir keine sorgen machen.
Also für Records mit fester größe immer new und dispose nutzen....hm

Zitat von himitsu:

und New+Dispose wie eine lokale managed Variable, bzw. wie Create und Destroy zum Objekt-Feld.

Dispose darf man dann aber auch nur einmal aufrufen?

Zitat von woodie:

ich habe im Beispiel nur alle 3 Varianten aufgeführt:

Code:

Setlength(AArray,0);
Finalize(AArray);
AArray:=nil;

um 'sicher' zu gehen, normalerweise nutze ich nur Setlength(AArray,0);

Die Frage ist aber immer noch, warum es mir von FastMM5 als Leak angezeigt wird.

Vielleicht brauchst du so eine Demo mit Log des Refcount wie Uwe Raabe sie für die verschiedenen New+Dispose, GetMem+Freemem und Declare + :=nil gemacht hat
Nur eben für diesen dreifach free.

[himitsu]

Zitat von QuickAndDirty:

Dispose darf man dann aber auch nur einmal aufrufen?

Per se ja.

Delphi-Quellcode:

procedure Dispose(P);
begin
  Finalize(P);
  FreeMem(P);
end;

Leider ist hier kein P := nil; enthalten, wie beim FreeAndNil,
aber wenn du es selbst danach machst, dann wäre ein Mehrfachaufruf OK.

Delphi-Quellcode:

New(P);
...
Dispose(P);
P := nil;

Und das Finalize selbst.
Ich bin mir nicht sicher, ob es "vollständig" den speicher nullt (hab das Gefühl, für einige Typen wird das nicht gemacht),
aber wenn nicht, dann würde hier ein ZeroMemory/FillChar nach dem Finalize helfen, damit es mehrmals aufgerufen werden kann.

[Uwe Raabe]

Zitat von QuickAndDirty:

Ich habe nie New+Dispose benutzt. Und ich dachte immer longstrings kümmern sich selbst um sich und da muss ich mir keine sorgen machen.
Also für Records mit fester größe immer new und dispose nutzen....hm

Ich habe schon ewig keine Pointer auf Records mehr benutzt und somit komme ich auch nicht in die Verlegenheit, für Records Speicher zu reservieren und diesen freizugeben. In der Regel kann man solche Fälle heutzutage anders lösen.

[TiGü]

Zitat von Der schöne Günther:

Vielleicht im Debugger noch einen der Strings in Visualizer gehabt? Da kann sowas passieren.

Hand hoch, wer auch schon mal einen halben Tag auf der Suche nach derartigen Speicherlecks verbracht hatte und sich immer wunderte, warum der FastMM beim Kollegen (ohne derartiges Untersuchungsobjekt in der Watch List) das Problem nicht anzeigte!

[Blup]

Mit Finalize muss man sehr vorsichtig sein, sonst erzeugt man an anderer Stelle eine Zugriffsverletzung.

Delphi-Quellcode:

type
  TMyRecord = record
    A: Integer;
    B: String;
    C: IInterface;
    procedure Clear;
  end;

implementation

procedure TMyRecord.Clear;
begin
  Finalize(Self);  // für Strings, Interfaces, Array usw.
  FillChar(Self, SizeOf(Self), 0);
end;

Finalize prüft ob B und C auf Nil verweisen.
Ist das nicht der Fall, wird der Referenzzähler des Strings oder Objects verringert.
Fällt der Referenzzähler auf 0 wird der String oder das Object freigegeben, der Inhalt der Variablen aber nicht verändert.
Durch FillChar verweisen B und C danach auf Nil.

[himitsu]

Delphi-Quellcode:

procedure TMyRecord.Clear;
begin
  Self := Default(TMyRecord);
end;

und eventuell noch bissl Custom-Managed-Records mit drauf.

https://docwiki.embarcadero.com/RADS...anaged_Records

[Stevie]

Zitat von TiGü:

Zitat von Der schöne Günther:

Vielleicht im Debugger noch einen der Strings in Visualizer gehabt? Da kann sowas passieren.

Hand hoch, wer auch schon mal einen halben Tag auf der Suche nach derartigen Speicherlecks verbracht hatte und sich immer wunderte, warum der FastMM beim Kollegen (ohne derartiges Untersuchungsobjekt in der Watch List) das Problem nicht anzeigte!

Auf Leak Reports während einer Debugging Session geb ich grundsätzlich gar nix.

[Stevie]

Zitat von Blup:

Mit Finalize muss man sehr vorsichtig sein, sonst erzeugt man an anderer Stelle eine Zugriffsverletzung.

Delphi-Quellcode:

type
  TMyRecord = record
    A: Integer;
    B: String;
    C: IInterface;
    procedure Clear;
  end;

implementation

procedure TMyRecord.Clear;
begin
  Finalize(Self);  // für Strings, Interfaces, Array usw.
  FillChar(Self, SizeOf(Self), 0);
end;

Finalize prüft ob B und C auf Nil verweisen.
Ist das nicht der Fall, wird der Referenzzähler des Strings oder Objects verringert.
Fällt der Referenzzähler auf 0 wird der String oder das Object freigegeben, der Inhalt der Variablen aber nicht verändert.
Durch FillChar verweisen B und C danach auf Nil.

Falsch, auch Finalize setzt die Felder von managed Types auf ihren "leer/nil" Status - denn genau dadurch wird der entsprechende Mechanismus hinter diesen Typen getriggert.

[himitsu]

Finalize ruft funktionionen auf, welche die einzelnen Typen finalisiert ... ich konnte aber in einigen der Funktionen nicht sehen, dass es dort auf 0 gesetzt wird.

[Blup]

Grad mit TMyRecord getestet:

In Delphi 12 werden die Variable von managed Types durch Finalize() auf nil gesetzt.
Selbst die Integer-Variable wird auf 0 gesetzt.

In Delphi 2007 werden die Variable von managed Types durch Finalize() auf nil gesetzt.
Die Integer-Variable behält aber den Inhalt.
FillChar() ist deshalb an dieser Stelle für Clear() sinnvoll.

Der mehrmalige Aufruf von Finalize() für die selbe Variable ist so problemlos möglich.
Ob das für noch ältere oder andere Compiler ebenfalls gilt?