ZIP File names memory leak

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

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

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

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

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.

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