Wie spürt man ein schwieriges Speicherleck mit fastMM auf?

Question

Nach dem Upgrade eines Projekts von Delphi 2007 auf Delphi 2009 bekomme ich ein Unbekanntes Speicherleck, bisher habe ich versucht, es mit fastMM aufzuspüren, hier ist, was fastMM Stack Trace Berichte:

A memory block has been leaked. The size is: 20

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
  at the time was:
40339E [System.pas][System][@GetMem][3412] 534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
562D48 [DBCommon.pas][DBCommon][TFilterExpr.PutExprNode][1583]
408E46 [System.pas][System][DynArraySetLength][20464]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]
528C1B [Forms.pas][Forms][TCustomForm.DoCreate][3260]
171A1A [GetRawStackTrace]

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

The allocation number is: 302844

Und manchmal habe ich das hier:

A memory block has been leaked. The size is: 20

This block was allocated by thread 0x111C, and the stack trace (return addresses) 
  at the time was:
40339E [System.pas][System][@GetMem][3412]
534873 [crtl][_malloc]
56D1C4 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3918]
56D316 [canex.cpp][MidasLib][DllGetDataSnapClassObject][3961]
77DC921A [RtlAnsiStringToUnicodeString]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
7726B8F5 [GetProcAddress]
7726B907 [GetProcAddress]
589B1E [ossrv.cpp][MidasLib][DllGetDataSnapClassObject][3163]
56D5EE [canex.cpp][MidasLib][DllGetDataSnapClassObject][4085]
408E92 [System.pas][System][@DynArraySetLength][20486]

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

Gibt es eine bessere Methode, um herauszufinden, was das Speicherleck wirklich verursacht?

Answer 1

Dieses Speicherleck wurde durch einen Delphi-Fehler verursacht, QC #67709

Das Problem wurde mit dem letzten Delphi 2009-Update behoben, kein Wunder, dass ich nicht in der Lage war, es zu beheben.

Answer 2

Solange die Größe des ausgelaufenen Speicherblocks nicht zunimmt, je länger/mehr Ihr Programm verwendet wird, ist dies kein Problem. Wenn Sie langlebige Objekte haben, die nur freigegeben werden, wenn Sie die Anwendung beenden, ist es dasselbe, als ob Sie sie auslaufen lassen würden - der gesamte Speicher wird bei Beendigung zurückgewonnen (es sei denn, sie haben Handles-Ressourcen außerhalb des Speichers).

Die Speicherlecks, um die Sie sich kümmern sollten, sind diejenigen, die sich im Laufe der Zeit oder der Nutzung ansammeln. Wenn es sich jedes Mal um 20 Byte handelt, ist das nicht weiter schlimm.

Answer 3

Ich weiß nicht, ob es irgendwelche Lecks in D2009 VCL gibt, also angenommen, das Leck ist in Ihrem Code, würde ich zuerst folgendes überprüfen:

• gibt es ein Array oder eine Liste (wegen der @DynArraySetLength ), die in diesem Formular erstellt wurde und nicht freigegeben wird, wenn Sie das Formular entsorgen.
• Gibt es irgendeine Funktion, die ein Objekt erzeugt und zurückgibt, das von einem externen Aufrufer freigegeben werden sollte, und wenn Sie diese Art von Funktion haben, prüfen Sie, ob der Aufrufer dieses Objekt freigibt.
• Wenn dies keine undichte Stelle ergibt, sollten Sie überprüfen, ob jedes Objekt, das Sie in Ihrem Formularcode erstellen, zerstört wird, wenn Sie das Formular zerstören.

Answer 4

Das letzte Mal, als ich ein rätselhaftes Leck dieser Art hatte, sah ich mir den Rohspeicher des betreffenden Objekts an - und sah Text, der mir zeigte, um welche Art von Daten es sich handelte. Wenn es sagt, dass es nicht weiß, welche Art von Objekt es ist, bedeutet das wahrscheinlich, dass es überhaupt kein Objekt ist - schauen Sie sich also dynamisch zugewiesene Dinge an, einschließlich Strings.

Answer 5

IIRC VCL hatte ein paar sehr kleine Lecks wie dieses, die man ohne große Bedenken ignorieren kann. Dies könnte eines von ihnen sein!? Ich hoffe, jemand kann diesen Punkt klären.