SetDelimitedText Memory Leak ?

[venice2]

Delphi-Quellcode:

var
  FileName: string;
  SplitPath: TstringList;
begin 
  SplitPath := TStringList.Create;
  SplitPath.StrictDelimiter:= true;
  SplitPath.Delimiter := '\';

  try
    SplitPath.DelimitedText := ExtractFilePath(FileName);

    SplitPath.DelimitedText := ''; // bringt nichts
    SplitPath.Clear;               // auch nichts
  finally    
    FreeAndNil(SplitPath);
  end;
end;

SetDelimitedText ist der letzte Aufruf (Memory Leak)

Es wird alles freigegeben trotzdem habe ich hier Speicherlecks.

[DieDolly]

Wenn ich deinen Code kopiere und statt dem ExtractFilePath(FileName) einen festen String nehme, habe ich keinen Leak.
Außerdem wird FileName nicht gesetzt.

[venice2]

Zitat:

Zitat von DieDolly (Beitrag 1459232)

Außerdem wird FileName nicht gesetzt.

Getippt und zur Demonstration nicht nötig.
Denke jeder weis was gemeint ist.

Mir meldet Eurekalog in dieser Zeile 30 Memory Leaks

Delphi-Quellcode:

SplitPath.DelimitedText := ExtractFilePath(Files[IntI - 1]);

Files ist ein array of String.

[himitsu]

Wo steht der Code?
Doch nicht etwa in einer Consolenanwendung in der DPR.
Wenn ja, dann verschieb das ganze mal in eine Prozedur.

Und welche Delphi-Verison?

[venice2]

Zitat:

Zitat von himitsu (Beitrag 1459238)

Wo steht der Code?
Doch nicht etwa in einer Consolenanwendung in der DPR.
Wenn ja, dann verschieb das ganze mal in eine Prozedur.

Und welche Delphi-Verison?

Nein normale Procedure.
Delphi 10.3.3 64 Bit.

Gebe ich einen normalen String ein so wie die @DieDolly habe ich das problem auch nicht.
Das ist aber nicht die Voraussetzung so wie in meinem Beispiel.

[Rolf Frei]

Ich vermute mal der entscheidende Teil deines Codes fehlt in deinem Beispiel. Was machst du mit dem Files Array? Gibst du das sauber frei?

[venice2]

Zitat:

Zitat von Rolf Frei (Beitrag 1459253)

Ich vermute mal der entscheidende Teil deines Codes fehlt in deinem Beispiel. Was machst du mit dem Files Array? Gibst du das sauber frei?

Delphi-Quellcode:

SetLength(Files, 0); // keine Auswirkung

Es wird auf den Copy befehl verzweigt.
Auch wenn ich den String selber splite.

Delphi-Quellcode:

Result[spCount - 1] := Copy(sTemp, 1, spPos - 1); // der leak soll hier entstehen

Das ist der letzte Aufruf in System

Delphi-Quellcode:

function _UStrCopy(const S: UnicodeString; Index, Count: Integer): UnicodeString;

[Rolf Frei]

Am Ende Files := nil oder Finalize(Files) nutzen. Damit sollte der String-Speicher freigegben werden, wenn ich mich hier nicht komplett irre.

Lies dir mal das dazu durch: https://www.drbob42.com/delphi4/dynarray.htm

[venice2]

Zitat:

Zitat von Rolf Frei (Beitrag 1459260)

Am Ende Files := nil oder Finalize(Files) nutzen. Damit sollte der String-Speicher freigegben werden, wenn ich mich hier nicht komplett irre.

Lies dir mal das dazu durch: https://www.drbob42.com/delphi4/dynarray.htm

Wenn ich das Array mit SetLength(Files, 0); auf 0 setze dann ist es NIL.
Beide Tips nutzen nichts. Danke, haben kein Auswirkung

[Rolf Frei]

Wenn ich dein Beispiel nehme und selber noch eine Files-Array erstelle (Array of String), bekomme ich keine Memoryleaks. Also muss irgendwas im Beispiel noch fehlen, das wir nicht wissen.

Mein Testcode ohne Memoryleaks. Wenn ich Testeshalber das FreeAndNil rausnehme, habe ich wie erwartet ein Memoryleak.

Delphi-Quellcode:

Im DPR:    ReportMemoryLeaksOnShutdown := True;

procedure TForm1.FormCreate(Sender: TObject);
var
  FileName: string;
  SplitPath: TstringList;
  s: Array of String;
begin
  SetLength(s, 2);
  s[0] := 'c:\asfdsdf\sdf';
  s[1] := 'c:\asfds2df\s2df';

  SplitPath := TStringList.Create;
  try
    SplitPath.StrictDelimiter:= true;
    SplitPath.Delimiter := '\';

    SplitPath.DelimitedText := ExtractFilePath(s[0]);

    SplitPath.DelimitedText := ''; // bringt nichts
    SplitPath.Clear; // auch nichts
  finally
    FreeAndNil(SplitPath);
  end;
end;

[venice2]

Zitat:

Zitat von Rolf Frei (Beitrag 1459263)

Wenn ich dein Beispiel nehme und selber noch eine Files-Array erstelle (Array of String), bekomme ich keine Memoryleaks. Also muss irgendwas im Beispiel noch fehlen, das wir nicht wissen.

Mein Testcode ohne Memoryleaks. Wenn ich Testeshalber das FreeAndNil rausnehme, habe ich wie erwartet ein Memoryleak.

Delphi-Quellcode:

Im DPR:    ReportMemoryLeaksOnShutdown := True;

procedure TForm1.FormCreate(Sender: TObject);
var
  FileName: string;
  SplitPath: TstringList;
  s: Array of String;
begin
  SetLength(s, 2);
  s[0] := 'c:\asfdsdf\sdf';
  s[1] := 'c:\asfds2df\s2df';

  SplitPath := TStringList.Create;
  try
    SplitPath.StrictDelimiter:= true;
    SplitPath.Delimiter := '\';

    SplitPath.DelimitedText := ExtractFilePath(s[0]);

    SplitPath.DelimitedText := ''; // bringt nichts
    SplitPath.Clear; // auch nichts
  finally
    FreeAndNil(SplitPath);
  end;
end;

So hatte ich es ja auch aber ich habe leaks warum auch immer.

[Moombas]

Dann poste doch mal deinen kompletten code, dann kann man dir sicherlich besser helfen.

[himitsu]

Schade, das wäre eine einfache Erklärung gewesen, da globale Variablen in der DPR erst entladen werden, nachdem der Speichermanager aufgeröumt wurde.

Zitat:

Zitat von venice2 (Beitrag 1459239)

Gebe ich einen normalen String ein so wie die @DieDolly habe ich das problem auch nicht.

"normale" String-Konstanten liegen nicht im Speichermanager. (die werden dierect aus dem Code verlinkt, mit ReferenceCounter = -1)


TStringList nutzt intern ein dynamisches Array mit den Strings der Zeilen,
da hätte ein Fehler schon lange auffallen müssen,
und im Setter des DelimitedText sollten die temporären Strings für das Zerlegen eigentlich auch automatisch aufgeräumt werden.

[venice2]

Ich habe es mit 2 Varianten versucht.
1 mal mit TStringList und einmal von Hand (also eigene Split Funktion)
Bei beiden funktioniert es nicht.
Stehe irgendwie auf dem Schlauch na gut ist halt so.

Seltsam ist nur das ich mit reinen Strings arbeite also keine Konvertierung von PWideChar, WideString oder der gleichen.
Trotzdem :evil:

Zitat:

Dann poste doch mal deinen kompletten code, dann kann man dir sicherlich besser helfen.

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.
Am ende gebe ich alles frei wie schon gezeigt aber die Leaks bleiben bestehen.

[hoika]

Hallo,
dann brauche wir ein compilierfähiges Minimalprojekt, also:
- leeres Projekt anlegen
- eine neue Unit (ohne DFM) anlegen
- deinen Code dort rein und in der DPR aufrufen.

Dann alles in eine Zip-Datei und hier hochladen (ohne die Exe).

[venice2]

Zitat:

Zitat von hoika (Beitrag 1459281)

Hallo,
dann brauche wir ein compilierfähiges Minimalprojekt, also:
- leeres Projekt anlegen
- eine neue Unit (ohne DFM) anlegen
- deinen Code dort rein und in der DPR aufrufen.

Dann alles in eine Zip-Datei und hier hochladen (ohne die Exe).

Danke für das Angebot.
Ich weis das es manchmal nötig ist Quelltexte zur Verfügung zu stellen aber ich sagte schon das bringt nichts ich kann es als Minimal Beispiel nicht auslegen.
Von daher wird mir wohl niemand helfen können muss mich da wohl selber durchbeißen.

[himitsu]

Zitat:

Zitat von venice2 (Beitrag 1459279)

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.

Joar, eine kleine Testanwenndung, mit nur dem Wichtigsten, würde schon reichen. :stupid:

[p80286]

Zitat:

Zitat von venice2 (Beitrag 1459279)

Den Quelltext hier zu posten bringt nichts da zu viele externe Funktionen aufgerufen werden die hier so niemand nachvollziehen kann.
Am ende gebe ich alles frei wie schon gezeigt aber die Leaks bleiben bestehen.

Wenn der bekannte Code keine Fehler produziert, Deiner hingegen schon, woran könnte das dann liegen?

Gruß
K-H

[hoika]

Hallo,

Zitat:

Am ende gebe ich alles frei.

Das sieht halt Delphi anders...

1.
Wenn es kein schleichender "Programm verbraucht immer mehr Speicher"-Fehler ist
-> ignorieren, Windows räumt ja eh auf

2.
Sollte es Punkt 1 sein, hilft hier nur radikal
- alle Aufrufe totlegen
- Programm starten, testen
- ersten Aufruf reinnehmen, testen

usw.

Das mussten wir bei uns schon öfters machen.
Was dann bei "altem, bewährten, war schon immer so Code" rauskaum, poste ich lieber nicht ;)

[TurboMagic]

Ist denn 100% sicher was da leakt?
Evtl. nämlich mal mit der vollen fastMM4 Version den Leakreport durchführen lassen,
denn der kann einem auch zeigen wo der Speicher allokiert wurde.
Evtl. leakt ja was anderes als gedacht.

Wobei ich mich da schon immer fragte, waru7m bei Delphi nicht diese volle Version
dabei ist, wenn die doch auch OpenSOurce ist...

[haentschman]

Moin...:P

Zitat:

Evtl. leakt ja was anderes als gedacht.

+1 :thumb: Denke ich auch.

[venice2]

Zitat:

Zitat von TurboMagic (Beitrag 1459317)

Ist denn 100% sicher was da leakt?
Evtl. nämlich mal mit der vollen fastMM4 Version den Leakreport durchführen lassen,
denn der kann einem auch zeigen wo der Speicher allokiert wurde.

Die frage ist was kann FastMM was EurekaLog nicht kann?

Zitat:

+1 Denke ich auch.

Denken ist so eine Sache.

[bernau]

Zitat:

Zitat von venice2 (Beitrag 1459365)

Die frage ist was kann FastMM was EurekaLog nicht kann?

Probier es doch einfach mal aus.

Zitat:

Zitat von venice2 (Beitrag 1459365)

Denken ist so eine Sache.

Sehr unfreundliche Antwort an jemanden der nur eine bestimmte These unterstützt.

[venice2]

Zitat:

Probier es doch einfach mal aus.

Es war eine Feststellung.
Ich verwende EurekaLog und das kann mindestens das was FastMM ebenfalls kann.
Es ist mir bekannt was den Leak verursacht nur ich kann ihn nicht beheben.

Zitat:

der nur eine bestimmte These unterstützt.

Das kann man auslegen wie einem gefällt.
Für mich hört es sich so an das der Dumme wie immer hinter der Tastatur sitzt.
Mit Thesen hat das nichts zu tun.

[himitsu]

Nja, es kommt drauf an, was/wieviel Embarcadero damals von Pierre gekauft hatte.
Und man hätte da dann noch so Einiges mehr umbauen müssen, also die ganzen Settings weg von Options-INC+IFDEF hin zu Variable/Parameter+IF-THEN,
denn die System-Unit neu zu kompilieren, nur um die Optionen zu ändern, geht nicht so gut.

Beim Debuggen ist Eurekalog das Schlimmste, was ich mir vorstellen kann (leidliche Erfahrung, wenn man bei Debuggen im Code/Assembler dessen Hooks landet und nicht mehr raus kommt)
und effektiv ist das Einzige, was wir beim Kunden wirklich zur Laufzeit nutzen, der Stacktrace und dafür müsste sich das Ding nicht so dermaßen penetrant überall reinhacken.



Für's Debugging gab es noch eine andere Memory-Debug-Komponente, die auch den Ersteller und die Zeit zu den Speicherblocks speichert/loggt und somit sagen kann von wem der Speicher "ursprünglich" stammt, welcher übrig bleibt,
bzw. wer zuerst den einen Speicher/Objekt freigab, wenn später nochmal jemand das machen will.

[haentschman]

Zitat:

Das kann man auslegen wie einem gefällt.

...und du hast es falsch ausgelegt. :?

Zitat:

Evtl. leakt ja was anderes als gedacht.

...war niemals auf dich bezogen sondern auf ein anderes Objekt in einem anderem Kontext. :roll: Wenn du dir den Schuh anziehst...

[venice2]

Zitat:

Zitat von haentschman (Beitrag 1459410)

Zitat:

Das kann man auslegen wie einem gefällt.

...und du hast es falsch ausgelegt. :?

Zitat:

Evtl. leakt ja was anderes als gedacht.

...war niemals auf dich bezogen sondern auf ein anderes Objekt in einem anderem Kontext. :roll: Wenn du dir den Schuh anziehst...

Dann tut es mir leid wenn ich das falsch aufgefasst habe.
Alles gut.

[haentschman]

:cheers: ...Biergarten.

[KodeZwerg]

Da wenig input kommt an denen man was erkennen könnte würde ich hoika's vorschlag mir zu herzen nehmen, auch wenn es je nach vielfalt des kodes lange dauern könnte.

Zitat:

Zitat von hoika (Beitrag 1459316)

- alle Aufrufe totlegen
- Programm starten, testen
- ersten Aufruf reinnehmen, testen

/ot
Hier ist auch ein EurekaLog Nutzer, mir gefällts, zum debuggen deaktivier ich's und hab null hooks
/ot

[himitsu]

Problem ist bei knapp 100 DLLs/BPLs, ist das irgendwo auch nur einen Hauch drin, schießt Eurekalog das ganze Programm ab,
anstatt nur eine Meldung auszugeben "keine Dedubinfos gefunden", kommt die Meldung und dann ein TerminateProcess.

Außerdem pfuscht der ECC an den Projektoptionen rum und zerballert die Debuginfos vom Delphi (klar, der hat ja seine eigenen "Besseren" und braucht den Rest nicht mehr), wodurch bei vielen Packages im Debugger oft keine Variablen aufgelöst werden können.