Warum meckert FastMM hier ein Speicherleck an?

[Benmik]

Folgender Code:

Delphi-Quellcode:

procedure TForm1.TuWas;
var i:integer; 
    Txt:string; 
    VerzListe:TStringList; 
    PathList:TJamPathList;
begin
  ...
  PathList              := TJamPathList.Create; // TJamPathList = TStringList
  VerzListe             := TStringList.Create;
  VerzListe.Sorted      := True;
  VerzListe.Duplicates  := dupIgnore;
  Try
    ...
    For i := PathList.Count - 1 downto 0 do
      VerzListe.Add(ExtractFileDir(PathList[i]));
  Finally
    PathList.OwnsObjects := True;
    FreeAndNil(PathList);
    VerzListe.OwnsObjects := True;
    FreeAndNil(VerzListe);
  End;

Der Memory-Manager meldet:

Zitat:

This application has leaked memory. The small block leaks are (excluding expected leaks registered by pointer):

13 - 20 bytes: UnicodeString x 1
85 - 100 bytes: TJamPathList x 1

Ich bin dem Code bis in System und System.Classes gefolgt, alles verläuft ordnungsgemäß.
Ich habe die Strings der Liste manuell auf '' gesetzt und alles Mögliche - FastMM meint, da sei ein Speicherleck.
Kann das sein, dass FastMM da Unsinn berichtet?

[Neutral General]

In deinem Code kann man nicht sehen ob/wo PathList:TJamPathList erstellt wird.

[Der schöne Günther]

Oder was es überhaupt ist. Laut diesem Link soll gelten

Delphi-Quellcode:

TJamPathList = class(TFilenameList);

aber was nun ein

Delphi-Quellcode:

TFilenameList

ist habe ich nirgendwo im Internetz finden können...

[hoika]

Hallo,
sicher, dass es genau diese Stelle ist?

Mache doch mal ein

Delphi-Quellcode:

PathList:= TJamPathList.Create;
try
  PathList.Add('Bla');
finally
  PathList.Free;
end;

[Benmik]

Steht in Shell_Win32:

Delphi-Quellcode:

TFilenameList = TStringList;

Ich habe es oben eingefügt. Ich hielt es nicht für wichtig, die Verzliste allein würde doch genügen. Ich habe es nur mit aufgenommen, da beide angemeckert werden.

@hoika:
Wenn ich nur

Delphi-Quellcode:

  JamPathList:= TJamPathList.Create;
  try
    JamPathList.Add('Bla');
  finally
    JamPathList.Free;
  end;

ausführe, bleibt FastMM stumm.
Was soll das bedeuten? Sowohl PathList als auch VerzListe sind lokale Variablen.

Ouuh, das war ein guter Hinweis. Die JamPathList wird in einer Routine GetListOfAllFiles gefüllt, in der die Liste nicht nur gefüllt, sondern auch erzeugt wird (!).

Delphi-Quellcode:

PathList := TJamPathList.Create;

mal weggelassen, funktioniert nicht nur, sondern die Warnung ist auch weg. Und zwar die Warnung bei Verzliste auch. Da komme ich vielleicht auch selbst dahinter, warum das so ist.

[hoika]

Hallo,

Zitat:

Was soll das bedeuten?

Das bedeutet, dass Du uns nicht den ganzen Code gezeigt hast.
Zeige doch mal etwas mehr Code, siehe weiter oben.
Vielleicht ist es auch eine völlig andere Stelle?

OK. hast du ;)
Was soll das OwnsObject?

Klammere alles aus, was in Deinem ... steht.
Auch das Sorted und Duplicates erst mal weg.

Dann immer weiter Code reinnehmen, bis Du die Stelle gefunden hast.


Und zuletzt läßt sich Dein Code gar nicht kompilieren

PathList:TJamPathList;
begin
...
JamPathList := TJamPathList.Create; // TJamPathList = TStringList

[TiGü]

Du hast PathList und JamPathList...eins davon gibst du nicht frei.

[Benmik]

Zitat:

Zitat von TiGü (Beitrag 1421285)

Du hast PathList und JamPathList...eins davon gibst du nicht frei.

Tut mir leid, das sind die gleichen Variablen, ich hatte das JamPathList einfach auf PathList gekürzt...

Das OwnsObject und Sorted sind Überbleibsel von meinen Versuchen, das Object manuell zu leeren...

Das war eine rasche Lösung, vielen Dank. Tut mir leid, dass ich mit der wechselnden Verwendung von JamPathList und PathList für Verwirrung gesorgt habe. JamPathList ist eine einfache Stringlist, und ich wollte dem Rätselraten vorbeugen, was eine JamPathList genau ist... Hatte leider einen paradoxen Effekt.

[Neutral General]

Wir brauchen den Code

[hoika]

Hallo,
hast Du denn jetzt mal alles nicht relevante ausgeklammert?

[Benmik]

Das Problem wurde durch hoika gelöst.

Die Stelle, die mir - im Nachhinein gesehen - hätte auffallen müssen, lautet:

Delphi-Quellcode:

JamPathList := JamShellLink.SelectionList.GetListOfAllFiles;

Dort wird eine TStringList zurückgegeben, die in GetListOfAllFiles erzeugt wird. JamPathList muss/darf also gar nicht erzeugt werden, daher ganz richtig das Speicherleck. Tschuldigung, FastMM!

Meiner Meinung nach ist die Routine ein Verstoß gegen das Gebot, dass Objekte dort freigegeben werden sollen, wo sie auch erzeugt werden. Daher hatte ich nicht damit gerechnet, hätte es aber müssen, denn was soll

Delphi-Quellcode:

JamPathList := ...

anderes bedeuten? Danke nochmal.

[hoika]

Hallo,
sehe ich auch so.
Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.

Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.

Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...

[Benmik]

Zitat:

Zitat von hoika (Beitrag 1421293)

Eigentlich müsste der Methode eine selbst erzeugte Liste übergeben werden.

Genau!

Interessant auch, wie zielgenau ich exakt diejenige Codezeile, die zur Lösung geführt hätte, als scheinbar (ja, scheinbar, nicht anscheinend!) unwichtig weggelassen hatte.

Auf der anderen Seite wundere ich mich immer, wie hier die Experten einen Fullpost von 500 Zeilen offenbar mit Lichtgeschwindigkeit durchparsen. Wahrscheinlich dauert es nicht mehr lang, bis die Compilerisierung eines Programmiererhirns als Berufskrankheit anerkannt wird.

[freimatz]

Zitat:

Zitat von hoika (Beitrag 1421293)

Hallo,
Wir haben hier ein paar ehemalige Java-Programmierer.
Die wollen das auch so machen, der Garbage Collector gibt ja schon alles frei.
Das aus den Köpfen zu bekommen, da sitze ich immer noch dran ...

Es wäre m.E. besser EMB würde mal dran sitzen um das Problem zu lösen. Ich verwende wo immer es geht interfaced Objekte. Zwar gilt auch "Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher" - jedoch habe ich hier auf Erden noch nie einen gefunden, der das fehlerfrei beherrscht. :P

[Benmik]

Da würde mich interessieren, auf welchem programmatischen Wege Emba das Problem lösen könnte.

[freimatz]

So wie es C# macht oder Delphi bei den interfaced Klassen. Da geht es ja auch.
Für eine einfache Klasse nur deswegen ein interface zu machen ist oft recht lästig.

[Benmik]

Oh, du meinst Garbage Collection einführen? Was macht dann himitsu? Seine Signatur ist doch mittlerweile eingebrannt und nicht mehr änderbar.

Meine Privatmeinung als Amateur: Wäre eine fundamentale Sprachänderung und erscheint undurchführbar.

[freimatz]

Nein, ich meine nicht Garbage Collection sondern Referenzzählung.
Allerdings lag ich mit C# falsch, die haben keine Referenzzählung sondern doch Garbage Collection.

Die Signatur ist eingebrannt? Aber dann ist sie doch Müll. Daraus folgt dass himitsu kein Delphianer ist :-P