TStringList und MemoryLeak (FastMM)

[Schwedenbitter]

Hallo,

bei folgendem Code:

Delphi-Quellcode:

// Einstellungen aus Registry laden
Procedure TSettings.Load;
Var
  S    : String;
Begin
  With TRegistry.Create(KEY_READ) Do
  Try
    RootKey:=HKEY_CURRENT_USER;
    Try
      If OpenKeyReadOnly(AdvoPfad) Then
      Begin
        ...
        S:=ReadString( 'aPopup' );   // Zu blockende Fenster
        If S = '' Then FPopBlock.Text:='Nur ein Fenster'
        Else           FPopBlock.Text:=S;// <- genau hier besteht das Problem
        ...
        CloseKey;
    Except End;
  Finally
    Free;
  End;
End;

erhalte ich mit FastMM folgende Meldung:

Code:

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

5 - 12 bytes: AnsiString x 1
13 - 20 bytes: AnsiString x 2
21 - 36 bytes: AnsiString x 1, Unknown x 1
53 - 68 bytes: TStringList x 1

wobei die letzte Meldung bzgl. der TStringList lt. konkreter Beschreibung von FastMM wohl dem mitgegebenen Code von Delphi anzulasten ist.
Wenn ich nun die beiden Zeilen mit den Zuweisungen an FPopBlock.Text (=TStringList) auskommentiere, bekomme ich nur noch die letzte Meldung.

Was hat das mit dem AnsiString zu bedeuten und wie bekomme ich es (wieder) weg?

Ich habe bereits die Hilfe benutzt. Das Problem i.V.m. FastMM scheint niemand zu haben. Ich habe nur herausgefunden, dass man wohl manchmal auch Strings leeren muss mit S:='';. Aber selbst, wenn ich das am Schluss einfüge, bleiben die Meldungen. Und ich verstehe auch nicht, warum er über einen AnsiString meckert, wo doch S eindeutig vom Typ String ist.

Gruß, Alex

[Mschmidt]

entweder bin ich blind - ich sehe in deinem Quellcode nichts von "TStringlist". Ist es wirklich die Stelle?
Mschmidt

[daywalker9]

Ich denke FPopupBLock ist die TStringListe..

[hoika]

Hallo,

ich würde mal die StringList wieder freigeben.


Heiko

[Schwedenbitter]

Danke für die Ideen. Ich hatte aber bereits geschrieben, dass es definitiv an diesen Zeilen liegt!

Zitat von hoika:

Hallo,
ich würde mal die StringList wieder freigeben.
Heiko

Delphi-Quellcode:

// Alles initialisieren
Constructor TSettings.Create;
Begin
  ...
  FPopBlock:=TStringList.Create;
  FPopBlock.Clear;
  ..
End;

Procedure TSettings.Load; // <- steht bereits oben

// Alles freigeben
Destructor TSettings.Destroy;
Begin
  FPopBlock.Free;
End;

Mehr geht leider nicht! Ich hatte ja geschrieben, dass

Zitat von Schwedenbitter:

Wenn ich nun die beiden Zeilen mit den Zuweisungen an FPopBlock.Text (=TStringList) auskommentiere, bekomme ich nur noch die letzte Meldung.

Da in meinem Hauptprogramm im OnDestroy ein TSettings.Free steht, wird die TStringList also freigegeben. FastMM meckert diese auch nicht an!
FastMM meckert den AnsiString an.

Gruß, Alex

[wicht]

Zitat:

Da in meinem Hauptprogramm im OnDestroy ein TSettings.Free steht, wird die TStringList also freigegeben.

Mit Debugger kontrolliert? Sorry für die dumme Frage...

[shmia]

Ein gefüllte TStringList enthält ja AnsiStrings (falls Delphi Version < 2010).
Daher ist es vollkommen logisch, dass eine nicht freigegebene StringList meistens auch weiteren Speicher für AnsiStrings reserviert hält.

Die Speicherlecks mit den AnsiStrings sind also nur eine Folge der nicht freigegebenen StringList.

Bei der Jagd auf Speicherlecks sollte man sich immer zuerst auf die Suche nach den grössten Objekten machen.
So bald man das Leck schliesst verschwinden damit häufig auch kleinere, untergeordnete Lecks.

[Schwedenbitter]

Ihr habt ja so Recht!

Ich habe dummer Weise mein TSettings von nichts abgeleitet. Der Compiler sieht damit offenbar keine Notwendigkeit den Destructor auszuführen. Wie auch immer.
Abhilfe hat nun geschaffen, dass ich mein TSettings von TObject abgeleitet habe. Ferner habe ich den Destructor mit dem Schlüsselwort Override versehen und nach dem FPopupBlock.Free noch ein Inherited und es gibt keine Meldungen mehr.
Manchmal sieht man den Wald vor lauter Bäumen nicht.

Gruß & Dank, Alex

P.S. Rein interessehalber: FastMM spricht an anderen Stellen ausdrücklich von TStringList. Warum macht er es hier nicht. Hätte er mir gesagt, dass eine TStringList nicht freigegeben wurde, wäre ich eher und ohne dahinter gekommen.

[mkinzler]

Zitat:

Abhilfe hat nun geschaffen, dass ich mein TSettings von TObject abgeleitet habe.

Von nichts abgeleitet heisst von TObject abgeleitet

[himitsu]

Der Compiler sieht damit offenbar keine Notwendigkeit den Destructor auszuführen. Wo hat er das nicht gesehn?
(du hast auch irgendwo ein Settings.Free stehn? )

Delphi gibt nichts von alleine frei oder ruft selbstständig Destruktoren auf.
(abgesehn von Interfaces und dynamischen Arrays, bzw. Strings, welche über die Compilermagic behandelt werden)



Und jupp, wird nix angegeben, dann wird implizit von TObjekt abgeleitet.
Bei Interfaces das Selbe, nur da halt von IInterface.