Wie heikel Speicherleck mit FastMM auf der Spur?

Question

ein Projekt von Delphi 2007 auf Delphi 2009 Nach dem Upgrade mir einen unbekannten Speicherleck bekommen, bisher habe ich tryin es aufzuspüren mit FastMM, 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 bekomme ich diese:

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 Art und Weise, was wirklich um herauszufinden, das Speicherleck verursacht?

Answer 1

Dieser Speicherverlust wurde von einem Delphi Fehler verursacht wird, QC # 67709

Es wird von dem letzten Delphi 2009 Update behoben wurde, kein Wunder, ich war nicht in der Lage, es zu beheben.

Answer 2

Solange die Größe des Blockspeichers durchgesickert nicht die mehr / mehr Ihr Programm wachsen verwendet wird, dann ist es kein Problem. Wenn Sie lange Gegenstände gelebt, die nur freigegeben werden, wenn Sie die Anwendung beenden, es ist das gleiche wie wenn man sie durchgesickert -. Alle Speicher auf Beendigung freigegeben wird (es sei denn natürlich haben sie Griffe Ressourcen über Speicher)

Der Speicherlecks Sie betroffen sein wollen diejenigen sind, die im Laufe der Zeit oder Verwendung akkumulieren. Wenn es 20 Bytes ist jedes Mal dann es nicht schwitzen.

Answer 3

Ich weiß nicht, ob es irgendwelche Lecks in D2009 VCL sind, so vorausgesetzt Leck in Ihrem Code ist, zuerst würde ich überprüfen folgende:

• gibt es eine Array oder eine Liste (wegen @DynArraySetLength) in dieser Form erstellt, die nicht freigegeben wird, wenn Sie Formular entsorgen.
• gibt es eine Funktion, die einige Objekte erstellt und zurückgibt, die von externen Anrufern befreit werden sollte, und wenn Sie diese Art von Funktionsprüfung, wenn Anrufer befreien das Objekt.
• wenn dies nicht Leck nicht verrät, dann sollten Sie prüfen, ob jedes Objekt, das Sie in Ihrem Formularcode erstellen, zerstört wird, wenn Sie die Form zerstören.

Answer 4

Das letzte Mal, dass ich in diese Richtung eine rätselhafte Leck hatte ich über den rohen Speicher des betreffenden Objekts sah - und sah Text, den mir gezeigt, welche Art von Daten es war. Wenn sie sagt, es nicht weiß, welche Art von Objekt ist es, dass wahrscheinlich bedeutet, dass es kein Objekt in erster Linie ist -. So sieht dynamisch zugewiesenen Dinge, einschließlich Strings

Answer 5

IIRC VCL hatte ein paar sehr kleine Lecks wie diese, die Sie ohne viel Sorge ignorieren können. Dies könnte einer von ihnen sein !? Hoffe, dass jemand diesen Punkt klarstellt.

Answer 6

Ich würde sagen, Sie etwas passiert in Ihrem Formular OnCreate Ereignishandler haben, die eine DynArray wächst.
Und das DynArray nicht am Ende freigegeben.
Aber ohne den Code zu sehen und zu debuggen es tatsächlich mit FastMM, dann ist es fast unmöglich zu erraten, was wirklich passiert.