FastMM log File

[Surrounder]

Hallo Forum,

ich hatte ein paar Probleme mit meiner Anwendung die ich geschrieben habe, und hatte jetzt einmal FastMM eingesetzt um noch Speicherlecks zu finden. Ich konnte auch einen großen Teil der Meldungen bearbeiten und das Problem zwischenzeitlich beheben.

Bei den jetzt noch im Log File eingetragenen Meldungen find ich aber leider keinen Ansatz. Die Quellcodezeile die mir angezeigt wird ist der Constructor der entsprechenden Klassen, nur weiss ich nicht was ich da falsch machen kann?

Kann man denn aus dem Logfile noch mehr herauslesen, als ich das bisher gedeutet habe? Bin für jeden Tip dankbar.

[Muetze1]

Es kommt mir eher so vor, als wenn du die Klassen anlegst und zum Teil als Result zurück gibst aber nicht mehr freigibst. Eine Rückgabe einer in einer Funktion erstellten Instanz ist eh schlecht - da es im Normalfall auf der gleichen Ebene wieder freigegeben werden sollte wo es auch instaziiert wird - und bei dir wäre das so oder so eine Aufrufebene höher.

[generic]

ja sehe ich auch so.
ich denke du hast "factories" bzw. class methoden welche objekte zurück geben.
aber ohne source kann man das nur schlecht sehen.

[Surrounder]

ok, ich stehe noch auf dem Schlauch und habs noch nicht ganz begriffen. Woran erkennt ihr denn das an dem Logfile?

Hier mal eine Stelle des Logfiles und der zugehörige Quellcode


--------------------------------2006/12/7 16:51:48--------------------------------
Ein Speicher-Leck hat folgende Größe : 28

Stackverfolgung - Speicherpuffer wurde zugeordnet (Rückgabeadresse):
40300E [FastMM4Messages.pas][System][System.@GetMem][135]
404BCF [FastMM4Messages.pas][System][System.TObject.NewInstance][135]
404F96 [FastMM4Messages.pas][System][System.@ClassCreate][135]
A2359A [Cl_Anlage.pas][Cl_Anlage][Cl_Anlage.TCLStation.CLStation][1539]
404BD8 [FastMM4Messages.pas][System][System.TObject.NewInstance][135]
A209AD [Cl_Anlage.pas][Cl_Anlage][Cl_Anlage.TCLAnlage.CLAnlage][275]
A1E068 [MainForm.pas][MainForm][MainForm.TMainWindow.ProgStartTimerTimer][355]
4A50AA [ExtCtrls][ExtCtrls.TTimer.Timer]
4A4F90 [ExtCtrls][ExtCtrls.TTimer.WndProc]

Der Speicherpuffer wird gegenwärtig für ein Objekt der folgenden Klasse verwendet: TCLStation

The allocation number is: 79476

Aktueller Speicherauszug von 256 Byte, angefangen an der Zeigeradresse: 2C7F068:
54 08 A2 00 00 00 00 00 78 00 D1 7F 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 14 84 5A F6
00 00 00 00 01 F9 C7 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8C 41 01 00 0E 30 40 00
41 5D 40 00 6C 5D 40 00 50 47 47 00 26 2E 4E 00 0F 2A 4E 00 BB 2D 4E 00 84 DB 47 00 53 6B 4D 00
8D 5C 40 00 5B 6B 40 00 E5 6A 40 00 C0 6B 40 00 92 4D 47 00 33 4C 40 00 8C 29 4E 00 EA E5 47 00
E0 E3 47 00 18 00 00 00 00 00 00 00 AE 5C B8 07 0C DE A5 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 51 A3 47 F8 80 80 80 80 00 00 00 00 41 F2 C7 02 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 C9 1D 01 00 0E 30 40 00 41 5D 40 00 05 64 40 00 57 89 47 00 FE 44 47 00
FD 68 47 00 99 38 47 00 BA 7D 47 00 4A 77 47 00 8D 5C 40 00 5B 6B 40 00 E5 6A 40 00 C0 6B 40 00
T . ¢ . . . . . x . Ñ  . . . . . . . . . . . . . . . . . „ Z ö
. . . . . ù Ç . . . . . . . . . . . . . . . . . Œ A . . . 0 @ .
A ] @ . l ] @ . P G G . & . N . . * N . » - N . „ Û G . S k M .
� \ @ . [ k @ . å j @ . À k @ . ’ M G . 3 L @ . Œ ) N . ê å G .
à ã G . . . . . . . . . ® \ ¸ . . Þ ¥ . € € € € € € € € € € € €
€ € € € € € € € Q £ G ø € € € € . . . . A ò Ç . . . . . . . . .
. . . . . . . . É . . . . 0 @ . A ] @ . . d @ . W ‰ G . þ D G .
ý h G . ™ 8 G . º } G . J w G . � \ @ . [ k @ . å j @ . À k @ .

Delphi-Quellcode:

constructor TCLStation.CLStation( SNr : ShortInt );
begin
   oldWellenTyp      := 0;
   SPS.WellenNummer       := 0;
   SPS.Speed       := 0;
   SPS.WellenTyp       := 0;
   Status          := SSleer;
   wellendat := TCLWellendaten.CLWellendat( SNr );
end

[Muetze1]

Er hat nicht über den Constructor selber gemeckert, sondern der Aufruf des Constructors stellt die Entstehung des nicht freigegebenen Speichers dar. D.h. dort wo der TCLStation Constructor aufgerufen wird, wird dieser nicht wieder am Ende freigegeben.

Dein geposteter Code: Du instanziierst TCLWellendaten und legst die Instanz ab. Gibst du diese Instanz im Destructor von TCLStation auch wieder frei? Ich glaube diesen Umstand auch in der log gesehen zu haben, daher die Frage...

[Surrounder]

ich gebe das meiner Meinung nach auch wieder richtig frei, und zwar im destructor von TCLStation

Delphi-Quellcode:

destructor TCLStation.dCLStation();
begin
   if Assigned( wellendat ) then begin
      wellendat.Destroy;
      wellendat := nil;
   end;
end;

und die Klasse TCLStation wird in der Klasse TCLAnlage erzeugt

Delphi-Quellcode:

constructor TCLAnlage.CLAnlage( );                                    ;
begin
         ...
   for i := 0 to dat.Anzahlstationen do begin                                    // Erzeugen der Klassenobjekte TCLStationen
      Station[i] := TCLStation.CLStation( i );
   end;
end;

und auch wieder frei gegeben

Delphi-Quellcode:

destructor TCLAnlage.dCLAnlage( );                                    
begin
         ...
   for i := 1 to dat.Anzahlstationen do begin                                    // Zerstören der Klassenelemente TCLStationen
      if Station[i] <> nil then begin
         Station[i].dCLStation;
         Station[i] := nil;
      end;
   end;
end;

[shmia]

Zitat von Surrounder:

ich gebe das meiner Meinung nach auch wieder richtig frei, und zwar im destructor von TCLStation

Delphi-Quellcode:

destructor TCLStation.dCLStation();
begin
   if Assigned( wellendat ) then begin
      wellendat.Destroy;
      wellendat := nil;
   end;
end;

Dein Code ist falsch bzw. "ungünstig programmiert".
Ein Destruktor muss heisst immer Destroy heisen!!
Andere Namen, wie z.B. beim Konstruktor möglich sind nicht erlaubt!!
Richtig ist:

Delphi-Quellcode:

destructor TCLStation.Destroy;
begin
   wellendat.Free;
   // Auf keinen Fall inherited vergessen !!!!!!!
   // da sonst ein Speicherleck entsteht
   // wichtig ist auch, dasss inherited im Destruktor die letzte Anweisung ist
   inherited;    
end;

Ich schätze, damit ist dein Speicherleck gefunden.

[Surrounder]

hmm ok, dann versuche ich das mal, denn ich habe das bei allen Klassen die ich gemacht habe so gemacht. Dann stelle ich jetzt alle destructoren auf den Namen Destroy um, vielleicht bringt es was

An das hatte ich schon einmal gedacht, es dann aber wieder verworfen weil eigentlich das ja gehen sollte dass man eigene Namen verwendet. Vermutlich ist das aber ein Problem weil die Klasse ja immer von irgend was abgeleitet ist und dort gibt es sicherlich ein Destroy.

[shmia]

Zitat von Surrounder:

hmm ok, dann versuche ich das mal, denn ich habe das bei allen Klassen die ich gemacht habe so gemacht. Dann stelle ich jetzt alle destructoren auf den Namen Destroy um, vielleicht bringt es was

Das bringt 1000%ig was.
Der Destruktor ist nämlich schon ab TObject eine virtuelle Methode.
Virtuelle Methoden können nur funktionieren, wenn man den gleichen Namen benützt.
Grundsätzlich kann es sehr viele Konstruktoren geben aber nur einen Destruktor.
Das gilt nicht nur für Delphi sondern auch für alle anderen OO Programmiersprachen.