ZIP File names memory leak

[Sherlock]

Himi nutzt wahrscheinlich einen SchlafManager

Sherlock

[Benmik]

Zitat von Sherlock:

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

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

[Rolf Frei]

Zitat von 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

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;