Array korrekt freigeben

[woodie]

Hallo zusammen ich habe folgenden Code:

Code:

var AString := 'Test;1';
var AArray := AString.Split([';']);

//...

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

Warum wird mir bei FastMM5 trotzdem ein Leak angezeigt? Was muss mit dem Array passieren, um den Leak zu unterbinden? oder ist die Split Funktion fehlerhaft?

Code:

A memory block has been leaked. The size is: 78

This block was allocated on 2025-09-23 15:28:03.379 by thread 10096, and the stack trace (return addresses) at the time was:
0096A473 [FastMM5.pas][FastMM5][FastMM_DebugGetMem_GetDebugBlock$qqrio][8039]
0096A53B [FastMM5.pas][FastMM5][FastMM_DebugGetMem$qqri][8075]
009478BA [System.pas][System][GetMem][4965]
0094CF9F [System.pas][System][NewUnicodeString][26083]
0094D1E0 [System.pas][System][UStrFromPWCharLen][26697]
0094E597 [System.pas][System][UStrCopy][32009]
009BADFF [System.SysUtils.pas][System.SysUtils][Sysutils.TStringHelper.InternalSplit][31746]
009BB040 [System.SysUtils.pas][System.SysUtils][Sysutils.TStringHelper.Split][31814]
009BAA52 [System.SysUtils.pas][System.SysUtils][Sysutils.TStringHelper.Split][31580]
01EE8B9C [Test.pas][Test][TTestItem.TestF1][1926]

[Thaddy]

Setlength(AArray,0);
Finalize(AArray); // <---

Dass ist doppel: double free. Beide machen dasselbe.

[Der schöne Günther]

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

Sowas elementares wie String.Split(..) wird ja kaum kaputt sein.

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

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

[bernau]

Zitat von Thaddy:

Setlength(AArray,0);
Finalize(AArray); // <---

Dass ist doppel: double free. Beide machen dasselbe.

Warum überhaupt freigeben (beide versionen)? Am Ende der Procedure ist es doch sowiso weg.

Auch würde ich nie auf die Idee kommen "AArray:=nil;" zu verwenden

[himitsu]

Zitat von bernau:

Auch würde ich nie auf die Idee kommen "AArray:=nil;" zu verwenden

Große Arrays, wenn sie nicht mehr gebraucht werden, mitten in der Methode freigeben, um Speicher für was Anderes freizumachen.