ZIP File names memory leak

[tumo]

Hallöchen,

Neulich habe ich die Delphi-interne Funktion zum Memory-Leaks "erkennen" für mich entdeckt (namentlich 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 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 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 class var , wenn die ZIP-Datei im Header kein UTF8 Flag gesetzt hat. Das wird dann im 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:

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 von himitsu:

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 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 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 von tumo:

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 von Uwe Raabe:

Zitat von himitsu:

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.