Seltsames Speicherleak-Problem mit Records in Verbindung mit Arrays

[s.h.a.r.k]

Nachdem wir gerade eh schon so viele schöne Record-Threads am laufen haben, habe ich mir gedacht, ich programmiere einfach mal eine Anwendung, welches sich mit Speicherleaks beschäftigt, die bei der Benutzung von Records auftreten Hier mal ein wenig Code:

Delphi-Quellcode:

type
  TDynIntArray = array of Integer;
  TStatIntArray = array[0..1] of Integer;
var
  Tmp : TStatIntArray;
  //Tmp : TDynIntArray;
  //Tmp : TArray<Integer>;
begin
  ReportMemoryLeaksOnShutdown := True;
  try
    // Set up a array with two elements
    //SetLength(Tmp, 2); // <- Für dyn. Arrays entkommentieren!
    Tmp[0] := 10;
    Tmp[1] := 3;

    // Diese Zeile liefert kein Speicherleak
    //TValue.From<Integer>(6).ToString();

    // Egal welcher dieser Zeilen aktiviert wird -> Speicherleak.
    // Darunter findet sich eine Beispielmeldung von FastMM4.
    Writeln( TValue.From<TStatIntArray>(Tmp).ToString() );
    //Writeln( TValue.From<TDynIntArray>(Tmp).ToString() );
    //Writeln( TValue.From<TArray<Integer>>(Tmp).ToString() );

    (*
    ---------------------------
    Project1.exe: Memory Leak Detected
    ---------------------------
    This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

    5 - 12 bytes: Unknown x 1
    13 - 20 bytes: Unknown x 1
    21 - 36 bytes: TValueDataImpl x 1
    *)
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

Kann mir jemand erklären, warum Delphi nicht erkennt, dass hier was selbstständig aufgeräumt werden muss?

Dieser Code (leicht gekürzt) hingegen funktioniert ohne Probleme und liefert keinerlei Speicherleak:

Delphi-Quellcode:

type
  TStatIntArray = array[0..1] of Integer;
var
  Tmp : TStatIntArray;
begin
    { ... }
    Tmp[0] := 10;
    Tmp[1] := 3;

    v := TValue.From<TStatIntArray>(Tmp);
    Writeln(v.ToString());
    { ... }
end.

Daher gehe ich mal davon aus, dass Delphi Probleme mit der Verwaltung der Anzahl der Zeiger, die auf den entsprechenden Record verweisen, hat. Oder warum gibt das sonst Probleme?

[Stevie]

Bekanntes Problem (bin gerade zu faul, den QC Eintrag herauszusuchen).
Problem ist an der Stelle, dass mit dem Rückgabeergebnis einer Funktion direkt weitergearbeitet wird.

[himitsu]

http://qc.embarcadero.com/wc/qcmain.aspx?d=44634

und da wundert man sich, warum ich kaum noch was dort reporte ... ändert sich ja eh nix

Sobald man aber den Record etwas verrößert (neue Felder einfügt), behebt sich das Problem oftmals von selber.

[Stevie]

Ah, das wars. Gemanagte Datentypen in einem Record und der als Funktionsergebnis.
Ergebnis der Funktion in einer Variable speichern und damit weitermachen behebt das Problem.

[himitsu]

Zitat von Stevie:

Ah, das wars. Gemanagte Datentypen in einem Record und der als Funktionsergebnis.

Eigentlich passiert es überall, aber bei ungemanagten Typen fällt es nicht auf.

[USchuster]

Zitat von Stevie:

Ah, das wars.

Nein, denn QC 44634 wurde in XE offenbar durch den Fix für QC 77903 behoben und in einigen Tagen wird QC den Status sicher entsprechend anzeigen.

[himitsu]

Nja, auch nur bedingt besser ... also daß man sich Bugfixes immer kaufen muß.

[Stevie]

Zitat von USchuster:

Zitat von Stevie:

Ah, das wars.

Nein, denn QC 44634 wurde in XE offenbar durch den Fix für QC 77903 behoben und in einigen Tagen wird QC den Status sicher entsprechend anzeigen.

Tja, kann ich nur sagen, dann haben sie es nicht richtig gefixt.

Boom:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

type
  TRecord2 = record
    FIntf: IInterface;
  end;

  TRecord1 = record
    FRecord2: TRecord2;
    function Foo: string;
  end;

function Get: TRecord1;
begin
  Result.FRecord2.FIntf := TInterfacedObject.Create;
end;

function TRecord1.Foo: string;
begin
  Result := '';
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  Get.Foo;
end.

Genau das passiert nämlich im Fall von TValue. Dort gibts intern das Feld FData vom Typ TValueData, worin wiederum eine Interface Referenz (IValueData) gespeichert wird. Daher auch der Memleak des TValueDataImpl Objektes.

[USchuster]

Zitat von Stevie:

Zitat von USchuster:

Zitat von Stevie:

Ah, das wars.

Nein, denn QC 44634 wurde in XE offenbar durch den Fix für QC 77903 behoben und in einigen Tagen wird QC den Status sicher entsprechend anzeigen.

Tja, kann ich nur sagen, dann haben sie es nicht richtig gefixt.

"Es" kann auch nicht gefixed werden, sondern nur konkrete Probleme in Form von Testfällen mit vollständigem Quellcode. QC 44634 ist gefixed, jedoch QC 75036 ist es nicht. Letzteres entspricht wohl dem Problem hier inkl. Deinem Beispiel. Wenn TRecord1 in einer Variable gespeichert wird

Delphi-Quellcode:

var
  R: TRecord1;
begin
  ReportMemoryLeaksOnShutdown := True;
  R := Get;
  R.Foo;
end.

, wie in QC 75036 oder Armins gekürztem Beispiel, dann gibt es kein Memoryleak. Damit Embarcadero es "diesmal" "richtiger" macht, schicke ich denen Armins gekürztes Beispiel in der kapputten Fassung.

[Stevie]

Zitat von USchuster:

"Es" kann auch nicht gefixed werden, sondern nur konkrete Probleme in Form von Testfällen mit vollständigem Quellcode.

Wenn man die Bugfixes nicht jedes Jahr wieder mit teuerem Geld bezahlen müsste, wäre die Bereitschaft, selber mehr Zeit in Fehlerdiagnosen zu stecken, sicher größer.