Как отследить хитрую утечку памяти с fastMM?

Question

После обновления проекта с Delphi 2007 до Delphi 2009 я получаю неизвестную утечку памяти, поэтому я пытался отследить ее с помощью fastMM, вот что сообщает трассировка стека fastMM:

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

И иногда я получаю это:

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

Есть ли лучший способ выяснить, что на самом деле вызывает утечку памяти?

Answer 1

Эта утечка памяти была вызвана ошибкой Delphi, QC # 67709

Это было исправлено последним обновлением Delphi 2009, неудивительно, что я не смог это исправить.

Answer 2

Пока размер протекающего блока памяти не увеличивается, чем дольше / дольше используется ваша программа, то это не проблема. Если у вас есть долгоживущие объекты, которые освобождаются только после завершения работы приложения, это аналогично тому, как если бы вы их утекли - вся память освобождается при завершении (если, конечно, они не обрабатывают ресурсы вне памяти).

Утечки памяти, о которых вы хотите знать, это те, которые накапливаются со временем или при использовании. Если каждый раз по 20 байт, то не переживайте.

Answer 3

В прошлый раз, когда у меня была загадочная утечка по этим линиям, я просмотрел необработанную память объекта-нарушителя и увидел текст, который показал мне, какие это были данные. Когда он говорит, что не знает, что это за объект, то это, скорее всего, означает, что это не объект в первую очередь - так что смотрите на динамически размещаемые объекты, включая строки.

Answer 4

Я не знаю, есть ли утечки в VCL D2009, поэтому, предположив, что в вашем коде есть утечка, сначала я бы проверил следующее:

• существует ли какой-либо массив или список (из-за @DynArraySetLength), созданный в этой форме, который не освобождается при удалении формы.
• есть ли какая-либо функция, которая создает и возвращает некоторый объект, который должен быть освобожден внешним вызывающим, и если у вас есть такая функция, проверьте, освобождает ли вызывающий объект этот объект.
• если это не выявляет утечку, то вам следует проверить, уничтожается ли каждый объект, который вы создаете в коде формы, когда вы уничтожаете форму.

Answer 5

Я бы сказал, что у вас в обработчике событий Form OnCreate что-то происходит с DynArray.
И этот DynArray не выпускается в конце.
Но, не видя код и не отлаживая его с помощью FastMM, почти невозможно догадаться, что на самом деле происходит.

Answer 6

IIRC VCL имел несколько очень маленьких утечек, которые можно игнорировать без особого беспокойства. Это может быть одним из них !? Надеюсь, кто-то прояснит этот момент.