ZIP File names memory leak

[tumo]

Hallöchen,

Neulich habe ich die Delphi-interne Funktion zum Memory-Leaks "erkennen" für mich entdeckt (namentlich

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

) und gehe jetzt ein paar meiner Projekte durch, um mich schämen zu können.

In meinem aktuellsten Projekt war es so schlimm, dass ich einfach alles von null begonnen und fein säuberlich wieder aufgebaut habe. Dabei vergleicht mein Programm den Inhalt eines ZIP-Archives mit einem vorhandenen Ordner, um fehlende Dateien zu erkennen. Zum Vergleichen erstelle ich je eine StringList, für den Ordner habe ich eine kleine Funktion geschrieben, alles prima.

Fürs ZIP-Archiv gibt es beim built-in TZipFile die geradezu perfekte Eigenschaft FileNames, die mir mein Leben paradiesisch einfach macht.

Delphi-Quellcode:

var
  zip: TZipFile;
  sl: TStringList;
begin
  zip := TZipFile.Create;
  zip.Open(APath, zmRead);
  sl := TStringList.Create;
  sl.AddStrings(zip.FileNames); // Ohne diese Zeile kein Leak
  zip.Free;
end;

Nun entsteht beim

Delphi-Quellcode:

zip.FileNames

offensichtlich ein TMBSCEncoding, dass nie korrekt freigegeben wird, jedenfalls meckert der Leak-Detektor am Ende rum. Das absolute Minimum um diesen Leak auszulösen ist übrigens

Delphi-Quellcode:

var
  zip: TZipFile;
begin
  zip := TZipFile.Create;
  zip.Open(AFile, zmRead);
  zip.FileNames; // Ohne diese Zeile kein Leak
  zip.Free;
end;

Nicht, dass mir ein Spaßvogel weise machen will, es muss woanders im Code sein.

Nun dir Frage: Ist das ein Fehler meinerseits, muss ich irgendwas ändern oder ist es ein Fehler der TZipFile Klasse?

Beste Grüße

[Andreas13]

Vielleicht hilft die Zeile

Delphi-Quellcode:

zip:= NIL;

weiter.
Gruß, Andreas

[Uwe Raabe]

Kann ich hier mit einer beliebigen Zip-Datei nicht reproduzieren.

TZipFile erzeugt aber innerhalb GetFileNames eine CP437-TEncoding

Delphi-Quellcode:

class var

, wenn die ZIP-Datei im Header kein UTF8 Flag gesetzt hat. Das wird dann im

Delphi-Quellcode:

class destructor

wieder freigegeben. Möglicherweise passiert das erst nach dem Leak-Report.

[sahimba]

Die TStringList am Ende freizugeben wäre hilfreich.

[himitsu]

Zitat:

Delphi-Quellcode:

var
  sl: TStringList;
begin
  ...
  sl := TStringList.Create;
  sl.AddStrings(...); // Ohne diese Zeile kein Leak
  ...
end;

Jupp, auch Ohne ein Leck.

Zitat:

Delphi-Quellcode:

zip.FileNames; // Ohne diese Zeile kein Leak

Wie und wo hast du denn diesen Codes getestet?
(z.B. in einem Konsolenprogramm, ohne etwas drumrum)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1466468)

Jupp, auch Ohne ein Leck.

Also, ich habe noch keine ZIP-Datei gefunden, die zu einem Memory-Leak führt. Offenbar sind hier alle UTF8.

[tumo]

Danke erstmal für die schnellen Antworten.

@Andreas13
Hat leider nicht geholfen.

@Uwe Raabe
Möglich ist es. Um das zu testen könnte man seine eigene Klasse mit

Delphi-Quellcode:

class var

schreiben. Bei einem schnellen Test hat das aber keinen Leak gebracht (im konkreten Beispiel hab ich eine Klasse mit class constructor/destructor geschrieben, die eine class var TStringList initialisiert/freet)

@sahimba
Passiert auch noch. Ich dachte nur, es hilft mehr, den Code zu sehen, der den Fehler auch auslöst.

@himitsu
Hab es erst nur in VCL-Projekten getestet (einfach ins FormCreate geschrieben und die Anwendung händisch geschlossen). Hab mir gerade noch einmal eine frische Konsolenanwendung genommen, wie detektiert man dort die Speicherleaks? Ein simples

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

scheint nicht zu funktionieren.

[tumo]

Damit ihr es auch reproduzieren könnt, hänge ich hier mal eine .zip an, mit der der Leak bei mir auftritt.

[Uwe Raabe]

Zitat:

Zitat von tumo (Beitrag 1466485)

Damit ihr es auch reproduzieren könnt, hänge ich hier mal eine .zip an, mit der der Leak bei mir auftritt.

Interessant! Hier wird kein Leak gemeldet. (Delphi 10.3.3)

Vielleicht doch ein komplettes Beispielprojekt?

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1466481)

Zitat:

Zitat von himitsu (Beitrag 1466468)

Zitat:

Delphi-Quellcode:

var
  sl: TStringList;
begin
  ...
  sl := TStringList.Create;
  sl.AddStrings(...); // Ohne diese Zeile kein Leak
  ...
end;

Jupp, auch Ohne ein Leck.

Also, ich habe noch keine ZIP-Datei gefunden, die zu einem Memory-Leak führt.

Da wird eine StringList erstellt, egal ob man ihr String hinzufügt oder nicht, dieses Objekt selbst ist schon ein Seicherleck, wenn man es nicht freigibt.

[tumo]

@Uwe Raabe
Jetzt wird es abenteuerlich. Aber ja, hier ein Beispielcode:

Project1:

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;

Unit1 implementation:

Delphi-Quellcode:

uses zip;

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
var
  zip: TZipFile;
begin
  zip := TZipFile.Create;
  zip.Open('C:\Users\[...]\Desktop\ActuallyAdditions-1.12.2-r151-2.zip', zmRead);
  zip.FileNames;
  zip.Free;
end;

[tumo]

Mal ne ganz andere Frage:
Wie sieht Dein class destructor vom TZipFile aus? bei mir freet er dort jedenfalls micht direkt das FCP437Encoding...

[Uwe Raabe]

Zitat:

Zitat von tumo (Beitrag 1466492)

Wie sieht Dein class destructor vom TZipFile aus? bei mir freet er dort jedenfalls micht direkt das FCP437Encoding...

Dies ist Delphi 10.3.3:

Delphi-Quellcode:

class destructor TZipFile.Destroy;
begin
  FCompressionHandler.Free;
  FCP437Encoding.Free;
end;

Bis 10.3.2 wird das noch nicht gemacht! Deswegen auch mein Hinweis auf die genaue Version, mit der ich das getestet habe.

[dataspider]

Delphi-Quellcode:

uses zip;
...
var
  zip: TZipFile;
...

Das sollte man vermeiden - Variablen gleich benennen wie eine Unit...

Frank

[Moombas]

Zitat:

Zitat von tumo (Beitrag 1466491)

Delphi-Quellcode:

uses zip;

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
var
  zip: TZipFile;
begin
  zip := TZipFile.Create;
  zip.Open('C:\Users\[...]\Desktop\ActuallyAdditions-1.12.2-r151-2.zip', zmRead);
  zip.FileNames;
  zip.Free;
end;

Was ist denn wenn du das in einen try...finally block packst:

Delphi-Quellcode:

uses zip;

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
var
  zip: TZipFile;
begin
  zip := TZipFile.Create;
  try
    zip.Open('C:\Users\[...]\Desktop\ActuallyAdditions-1.12.2-r151-2.zip', zmRead);
    zip.FileNames;
  finally
    zip.Free;
  end;
end;

[Uwe Raabe]

Ich vermute, es liegt an der Delphi-Version. 10.3 ist eben nicht immer gleich 10.3.

[Benmik]

Himitsu, Heute, 2:45 Uhr
Himitsu, Heute, 9:58 Uhr
Alle Achtung. Da hätte ich ein Schlafleck, weil mein Tagesstress nicht freigegeben wurde.

[Sherlock]

Himi nutzt wahrscheinlich einen SchlafManager ;-)

Sherlock

[Rolf Frei]

Zitat:

Zitat von tumo (Beitrag 1466463)

Hallöchen,

Neulich habe ich die Delphi-interne Funktion zum Memory-Leaks "erkennen" für mich entdeckt (namentlich

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown := true;

) und gehe jetzt ein paar meiner Projekte durch, um mich schämen zu können.

In meinem aktuellsten Projekt war es so schlimm, dass ich einfach alles von null begonnen und fein säuberlich wieder aufgebaut habe. Dabei vergleicht mein Programm den Inhalt eines ZIP-Archives mit einem vorhandenen Ordner, um fehlende Dateien zu erkennen. Zum Vergleichen erstelle ich je eine StringList, für den Ordner habe ich eine kleine Funktion geschrieben, alles prima.

Fürs ZIP-Archiv gibt es beim built-in TZipFile die geradezu perfekte Eigenschaft FileNames, die mir mein Leben paradiesisch einfach macht.

Delphi-Quellcode:

var
  zip: TZipFile;
  sl: TStringList;
begin
  zip := TZipFile.Create;
  zip.Open(APath, zmRead);
  sl := TStringList.Create;
  sl.AddStrings(zip.FileNames); // Ohne diese Zeile kein Leak
  zip.Free;
end;

Nun entsteht beim

Delphi-Quellcode:

zip.FileNames

offensichtlich ein TMBSCEncoding, dass nie korrekt freigegeben wird, jedenfalls meckert der Leak-Detektor am Ende rum. Das absolute Minimum um diesen Leak auszulösen ist übrigens

Delphi-Quellcode:

var
  zip: TZipFile;
begin
  zip := TZipFile.Create;
  zip.Open(AFile, zmRead);
  zip.FileNames; // Ohne diese Zeile kein Leak
  zip.Free;
end;

Nicht, dass mir ein Spaßvogel weise machen will, es muss woanders im Code sein.

Nun dir Frage: Ist das ein Fehler meinerseits, muss ich irgendwas ändern oder ist es ein Fehler der TZipFile Klasse?

Beste Grüße

Du solltest dir unbedingt angewöhnen alle erstellen Objekte mit einem try/finally zu schützen. Bei deinem Beispiel kräuseln sich beim mir alle Nackenhaare. Wird hier beim Open eine Exception ausgelöst, z.B. weil das File nicht exisitert, hast du ein massives Speicherloch, weil das TZipFile nicht mehr freigegeben wird. sl gibst du überhaupt nicht mehr frei.

Delphi-Quellcode:

var
  zip: TZipFile;
  sl: TStringList;
begin
  zip := TZipFile.Create;
  try
    zip.Open(APath, zmRead);
    sl := TStringList.Create;
    try
      sl.AddStrings(zip.FileNames); // Ohne diese Zeile kein Leak
    finally
      sl.Free;
    end;
  finally
    zip.Free;
  end;
end;

oder in diesem Fall könntest du das "sl" auch im äusseren try/finally freigeben, weil "sl" NIL ist solange es ncht erzeugt wurde und es so beim Free keien Problem gibt. Free überprüft ob die Instanz NIL ist.

Delphi-Quellcode:

var
  zip: TZipFile;
  sl: TStringList;
begin
  zip := TZipFile.Create;
  try
    zip.Open(APath, zmRead);
    sl := TStringList.Create;
    sl.AddStrings(zip.FileNames); // Ohne diese Zeile kein Leak
  finally
    sl.Free;
    zip.Free;
  end;
end;

[Benmik]

Zitat:

Zitat von Sherlock (Beitrag 1466516)

Himi nutzt wahrscheinlich einen SchlafManager

So einen Schlafmanager habe ich allerdings auch ...

[tumo]

@Uwe Raabe
Jup, das ist es. Ich hab 10.3.1

@dataspider
Gut zu wissen. War jetzt beim Beispiel nicht meine Priorität.

@Moombas
Ändert nichts, das Free wird ja so oder so aufgerufen.

@Rolf Frei
Zur Kenntnis genommen. Noch mehr Arbeit beim überfliegen alter Projekte :/

[Moombas]

Zitat:

Zitat von tumo (Beitrag 1466563)

@Moombas
Ändert nichts, das Free wird ja so oder so aufgerufen.

Wenn ich mich nicht irre, ist deine Aussage nicht richtig. Es wird nur mit aufgerufen, wenn es vorher keinen "Fehler" (Exception) gab.
Wenn du es in einem try...finally Block packst wird es jedoch definitiv immer ausgeführt: https://de.wikibooks.org/wiki/Progra...rwendet%20wird.

Korrigiert mich wenn ich da nun etwas falsch verstanden habe.

[scrat1979]

Zitat:

Zitat von Moombas (Beitrag 1466685)

Zitat:

Zitat von tumo (Beitrag 1466563)

@Moombas
Ändert nichts, das Free wird ja so oder so aufgerufen.

Wenn ich mich nicht irre, ist deine Aussage nicht richtig. Es wird nur mit aufgerufen, wenn es vorher keinen "Fehler" (Exception) gab.
Wenn du es in einem try...finally Block packst wird es jedoch definitiv immer ausgeführt: https://de.wikibooks.org/wiki/Progra...rwendet%20wird.

Korrigiert mich wenn ich da nun etwas falsch verstanden habe.

Korrekt, das Free wird nur aufgerufen wenn es im finally-Block steht. Ohne Exception-Handling (also ohne try...finally) wird das Free nicht aufgerufen.

[Andreas13]

Zitat:

Zitat von scrat1979 (Beitrag 1466744)

Zitat:

Zitat von Moombas (Beitrag 1466685)

Zitat:

Zitat von tumo (Beitrag 1466563)

@Moombas
Ändert nichts, das Free wird ja so oder so aufgerufen.

Wenn ich mich nicht irre, ist deine Aussage nicht richtig. Es wird nur mit aufgerufen, wenn es vorher keinen "Fehler" (Exception) gab.
Wenn du es in einem try...finally Block packst wird es jedoch definitiv immer ausgeführt: https://de.wikibooks.org/wiki/Progra...rwendet%20wird.

Korrigiert mich wenn ich da nun etwas falsch verstanden habe.

Korrekt, das Free wird nur aufgerufen wenn es im finally-Block steht. Ohne Exception-Handling (also ohne try...finally) wird das Free nicht aufgerufen.

Sorry, aber das stimmt nicht: Der Finally...End; - Block wird regulär immer ausgeführt, nur dann nicht, wenn die Routine vor dem Try durch eine Exit-Anweisung verlassen wird. Wenn zwischen dem Try ... Finally - Block ein Fehler passiert, dann wird der Finally...End; - Block auf jeden Fall noch ausgeführt, bevor die Routine beendet wird.
Gruß, Andreas

[Moombas]

Ok, also ich denke das scrat und ich beide das durchaus so meinten, unter der Bedingung, das man kein explizites verlassen des Blocks (Exit) anstößt @Andreas13.

Aber unwichtig das zu erwähnen war es dennoch nicht.

[scrat1979]

Zitat:

Zitat von Andreas13 (Beitrag 1466749)

Zitat:

Zitat von scrat1979 (Beitrag 1466744)

Zitat:

Zitat von Moombas (Beitrag 1466685)

Zitat:

Zitat von tumo (Beitrag 1466563)

@Moombas
Ändert nichts, das Free wird ja so oder so aufgerufen.

Wenn ich mich nicht irre, ist deine Aussage nicht richtig. Es wird nur mit aufgerufen, wenn es vorher keinen "Fehler" (Exception) gab.
Wenn du es in einem try...finally Block packst wird es jedoch definitiv immer ausgeführt: https://de.wikibooks.org/wiki/Progra...rwendet%20wird.

Korrigiert mich wenn ich da nun etwas falsch verstanden habe.

Korrekt, das Free wird nur aufgerufen wenn es im finally-Block steht. Ohne Exception-Handling (also ohne try...finally) wird das Free nicht aufgerufen.

Sorry, aber das stimmt nicht: Der Finally...End; - Block wird regulär immer ausgeführt, nur dann nicht, wenn die Routine vor dem Try durch eine Exit-Anweisung verlassen wird. Wenn zwischen dem Try ... Finally - Block ein Fehler passiert, dann wird der Finally...End; - Block auf jeden Fall noch ausgeführt, bevor die Routine beendet wird.
Gruß, Andreas

So war es gemeint :!::thumb:

Habe mich wohl missverständlich ausgedrückt.

[himitsu]

Egal ob Goto, Exit, Exception oder sonstwie, das Finaly wird immer ausgeführt.
(bei Goto sollte der Compiler es verbieten, dass man in/aus einem Try-Finally/Except springt)

Einzig beim Halt bzw. TerminateProcess ist alles zuspät.

[Andreas13]

Zitat:

Zitat von himitsu (Beitrag 1466764)

..Egal ob Goto, Exit, Exception oder sonstwie, das Finaly wird immer ausgeführt...

Stimmt nur beding, denn wenn Du Exit vor Try hast, wird der Finally-Block nicht ausgeführt.
Andreas

[himitsu]

Zitat:

Zitat von Andreas13 (Beitrag 1466767)

Zitat:

Zitat von himitsu (Beitrag 1466764)

..Egal ob Goto, Exit, Exception oder sonstwie, das Finaly wird immer ausgeführt...

Stimmt nur beding, denn wenn Du Exit vor Try hast, wird der Finally-Block nicht ausgeführt.
Andreas

Ja kla, die Aussagen beziehen sich natürlich immer nur auf das im/zwischen Try-Fiually,
drum kommt auch ein Create vor das Try, was im Finally Free werden soll. (nachdem/wenn es erstellt wurde)