Seltsames Speicherleak-Problem mit Records in Verbindung mit Arrays

[s.h.a.r.k]

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

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 :mrgreen:

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 :roll:

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:

Zitat von Stevie (Beitrag 1099626)

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? :lol:

[himitsu]

Ich mach wegen sowas auch keinen Testcode mehr direkt in die DPR ... zumindestens nicht ins

Delphi-Quellcode:

begin ... end.

davon,
also mindestens in eine Procedur ausgelagert und auf globale Variablen sollte man bei sowas auch verzichten.

[s.h.a.r.k]

Bin auch eher durch Zufall auf das Problem gestoßen, da ich mir eigentlich immer eine Testklasse anlege, um den Code innerhalb der Main-Methode einigermaßen clean und übersichtlich zu halten. Wollte dann schnell was testen und *BOOM*... Hab mich gerade mal wieder ein wenig verschiedene Blogs gekämpft und es ist eigentlich echt frustrierend, wie viele Feinheiten man wissen muss/sollte, sodass man nicht an jeder zweiten Ecke einen Memoryleak erhält. Gleiches trifft dann ja leider auch auf den User des Codes zu, der den Code dann später mal verwendet -- ausgehend davon, dass man den Code nicht nur für sich selber schreibt.

[himitsu]

Mein letztes Speicherproblem mit diesen Records, Generics und Co. war ja eher, daß Delphi mal zuviel freigibt ... so zur abwechslung :lol:
(will etwas doppelt freigeben)

[BUG]

Zitat:

Zitat von Stevie (Beitrag 1099626)

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 :gruebel:

[s.h.a.r.k]

In dem Fall ist es wahrlich keine anonyme Methode. Das Problem hat eher was mit dem reference to zu tun:

Delphi-Quellcode:

type TFunc = reference to function...

[Stevie]

Zitat:

Zitat von s.h.a.r.k (Beitrag 1099723)

Du machst Witze, oder? :lol:

Nein.

Zitat:

Zitat von BUG (Beitrag 1099744)

Nur mal so nebenbei, welche Funktion ist hier den anonym :gruebel:

Ja ich weiß, method reference wäre politisch korrekt gewesen. 8-)