Seltsames Speicherleak-Problem mit Records in Verbindung mit Arrays

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

[s.h.a.r.k]

AHHHH... Sowas ist doch Käse. Vor allem, weil es diesen Fehler wohl schon sehr, sehr lange gibt und er immer noch nicht gefixt wurde

Naja, das ganze klagen hilft leider nicht sehr viel, da es am Status im Moment nur sehr wenig bis gar nichts ändern wird. Zum Glück kann ich daher aber meinen Code einfach belassen, man muss ihn halt einfach nur anders nutzen.

Herzlichen Dank für euer Know How! Ich seh schon, ich sollte auch mal grob über das QC drüber schauen -- aber da steht eben auch nicht gerade wenig, was dann in einem ziemlichen Aufwand ausufern könnte...

-- Edit: Wow... Es wird echt immer besser

Delphi-Quellcode:

type
TApDynamicArray<T> = record
public type
  TApArrayToStringFunc = reference to function(Value: T): String;
public
  function ToString(const ToStrFunc: TApArrayToStringFunc): String;
end;

function TApDynamicArray<T>.ToString(const ToStrFunc: TApArrayToStringFunc): String;
begin
end;


procedure PrintIntegerArray(A: TApDynamicArray<Integer>);
begin
  Writeln( A.ToString(IntToStr) );
end;

var
  Tmp : TApDynamicArray<Integer>;
begin
  ReportMemoryLeaksOnShutdown := True;
  //Writeln( Tmp.ToString(IntToStr) );
  PrintIntegerArray(Tmp)
end.

... liefert in der aktuell gezeigten Version kein Speicherleak. Wenn ihr allerdings PrintIntegerArray() entfernt und das Writeln() aktiviert, dann kommt ein nettes Speicherleak zustande. Da fällt mir nur noch folgendes ein: WTF

Code:

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

13 - 20 bytes: Project1$1697$ActRec x 1

Entfernt man das reference to beim Typen TApArrayToStringFunc, dann funktionieren beide Versionen. Ist doch alles echt so super... Jetzt fang ich dann auch noch an, jeden scheiß zu überladen und auszubauen und hoffe, dass der Compiler alles mal in 10 Jahren auf die Reihe bring.

[Stevie]

Das hat was mit einer anonymen Methode in der main der dpr zu tun.

Boom:

Delphi-Quellcode:

procedure Foo(f: TFunc<Integer, string>);
begin
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  Foo(IntToStr);
end.

Seit ich das weiß, mach ich keine Testanwendungen mehr als Consoleprojekt (zumindest nicht die, wo ich regen Gebrauch von delegates mache)

[s.h.a.r.k]

Zitat von Stevie:

Das hat was mit einer anonymen Methode in der main der dpr zu tun.
[...]
Seit ich das weiß, mach ich keine Testanwendungen mehr als Consoleprojekt (zumindest nicht die, wo ich regen Gebrauch von delegates mache)

Du machst Witze, oder?

[BUG]

Zitat von Stevie:

Das hat was mit einer anonymen Methode in der main der dpr zu tun.

Boom:

Delphi-Quellcode:

procedure Foo(f: TFunc<Integer, string>);
begin
end;

begin
  ReportMemoryLeaksOnShutdown := True;
  Foo(IntToStr);
end.

Nur mal so nebenbei, welche Funktion ist hier den anonym