FastMM4, wie liest man die Protokolldatei?

Question

Ich arbeite an einer Software, also habe ich gerade begonnen, FastMM4 (für echt) in meinem Projekt zu verwenden.

Ich habe im Netz auf über gefunden, wie man die line number in FastMM4 erhält, ich habe die Zeilennummer, aber ich kann herausfinden, was die anderen Informationen im Protokoll bedeutet?

Ich habe dies in der Protokolldatei

This block was allocated by thread 0x15F8, and the stack trace (return addresses) at  the time was: 
402E86 [system.pas][System][System.@GetMem][2648] 
403A3B [system.pas][System][System.TObject.NewInstance][8824] 
403DAA [system.pas][System][System.@ClassCreate][9489] 
403A70 [system.pas][System][System.TObject.Create][8839] 
46A257 [u_home.pas][u_home][u_home.TForm1.SpeedButton1Click][80] {<-memory leak is here, but what are the Other detections?} 
443AAC [Controls.pas][Controls][Controls.TControl.Click][5226] 
46958B [Buttons.pas][Buttons][Buttons.TSpeedButton.Click][1211] 
46956B [Buttons.pas][Buttons][Buttons.TSpeedButton.MouseUp][1204] 
443FB2 [Controls.pas][Controls][Controls.TControl.DoMouseUp][5352] 
441BA0 [Controls.pas][Controls][Controls.TControl.SetMouseCapture][4379] 
444042 [Controls.pas][Controls][Controls.TControl.WMLButtonUp][5364] 

The block is currently used for an object of class: TStringList 

The allocation number is: 440 

in das der leak ist

46A257 [u_home.pas][u_home][u_home.TForm1.SpeedButton1Click][80] {<-memory leak is here, but what are the Other detections?} 

meinen Code

procedure TForm1.SpeedButton1Click(Sender: TObject); 
    var 
    str : TStringList; 
    begin 
    str := TStringList.Create; {<--im not freeing the, so leak} 

    end; 

und hier ist die call stack

i am Netz gesucht, aber ich weiß nicht, was die anderen Erkennungen sind ...

402E86 [system.pas][System][System.@GetMem][2648] 
403A3B [system.pas][System][System.TObject.NewInstance][8824] 
403DAA [system.pas][System][System.@ClassCreate][9489] 
403A70 [system.pas][System][System.TObject.Create][8839] 

{Other then this} 
46A257 [u_home.pas][u_home][u_home.TForm1.SpeedButton1Click][80] {<-memory leak is here, but what are the Other detections?} 
{Other then this} 

443AAC [Controls.pas][Controls][Controls.TControl.Click][5226] 
46958B [Buttons.pas][Buttons][Buttons.TSpeedButton.Click][1211] 
46956B [Buttons.pas][Buttons][Buttons.TSpeedButton.MouseUp][1204] 
443FB2 [Controls.pas][Controls][Controls.TControl.DoMouseUp][5352] 
441BA0 [Controls.pas][Controls][Controls.TControl.SetMouseCapture][4379] 
444042 [Controls.pas][Controls][Controls.TControl.WMLButtonUp][5364] 

im mit delphi 2006

i geöffnet haben und versucht, die gleich delphi 6, delph 7 auch

geprüft Ich habe festgestellt, dass dies in Zusammenhang mit FastMM $ Erkennung und Registrierung von einigen Lecks, die bereits in Delphi ist. How to track down tricky memory leak with fastMM? und dies für die Registrierung des Lecks, aber sind sie Fehler? Using FastMM4, how to register leaked string?

Auch FastMM4, Delphi6, Leak of TApplication?

ODER are they just the steps leading to the memory leak?

Answer 1

Was Sie im Protokoll hat, gibt es den Call-Stack, der in der Speicherzuordnung geführt, die durchgesickert.

Sie können sehen, wie nützlich es in der Aufrufliste in Ihrer Frage ist. Stellen Sie sich vor, dass Sie die oberste Zeile nur hatte, den Anruf, in dem Leck führte

402E86 [system.pas][System][System.@GetMem][2648] 

, dass Informationen über seine eigenen ziemlich nutzlos ist, da alle Heapzuweisungen durch GetMem gehen. Es ist der Aufruf-Stack, der Sie auf die Ereignisse verweist, die zum Aufruf von GetMem geführt haben. Und genau das zeigt, was das Leck verursacht hat.

Answer 2

FastMM hat keine Möglichkeit, die Absicht hinter dem Code zu erraten und festzustellen, welcher Befehl, der eine Speicherzuweisung verursacht, eine entsprechende Anweisung zum Freigeben haben sollte.

Denken Sie daran, dass FastMM nur eine Aufzeichnung der gesamten Speicherzuweisung während der Ausführung Ihres Codes speichert.
Es weiß nicht, warum, wie oder wo ein Leck auftritt, nur, dass Sie diese bestimmte Zuweisung zu dem Zeitpunkt nicht freigegeben haben, wenn Ihre Anwendung heruntergefahren wird und alles sauber sein soll.

Also, wenn ein Leck gemeldet wird, ist es wirklich eine Zuordnung, die angezeigt wird.
FastMM kennt Ihre Anwendung nicht und kann nur die gesamte Aufrufkette anzeigen, die zu diesem bestimmten Punkt im Code führt, an dem Sie Speicher zuweisen (normalerweise einer von mehreren Millionen GetMem-Aufrufen).
Die sinnvolle Information kann gefunden werden, indem Sie die Leiter hinaufgehen, bis Sie die höhere Anweisung finden, die etwas Speicher benötigt, wie eine TButton.Create und sehen, ob diese bestimmte Schaltfläche freigegeben wurde oder nicht (leaking all seinen Inhalt), oder wie ein TMyBadButton.Create erstellt einige AltBitmap, gibt sie jedoch nie frei.
In einem Fall das Leck ist in der Anwendung Code Creainge eine Schaltfläche ohne es zu befreien, in dem anderen Fall ist es in der TMyBadButton Komponente Code.

aktualisieren: Sie nützlich, diese alte Coderage Sitzung Memory Leaks for Dummies