How to track down tricky memory leak with fastMM?

Question

After upgrading a project from Delphi 2007 to Delphi 2009 I'm getting an Unknown memory leak, so far I've been tryin to track it down using fastMM, here is what fastMM stack trace reports:

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

And sometimes I get this:

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

Is there some better way to figure out what really is causing the Memory leak?

Spahi

Answer 1

This memory leak was being caused by a Delphi bug, QC #67709

It was fixed by the last Delphi 2009 update, no wonder I wasn't able to fix it.

Spahi

This is the QC: QC #67709 TClientDataSet.Locate memory leak detected The application reports memory leak upon application termination whenever TClientDataSet.Locate function is being called, with MIDASLIB in uses list. There is no memory leak if MIDASLIB is not in uses list. – Koontz

Answer 2

As long as the size of the memory block leaked does not grow the longer/more your program is used, then it isn't a concern. If you have long lived objects that are only freed when you terminate the application it is the same as if you leaked them - all memory is reclaimed on termination (Unless of course they have handles resources beyond memory).

The memory leaks you want to be concerned with are the ones that accumulate over time or usage. If it is 20 bytes everytime then don't sweat it.

Courante

It is creating one or more 20 bytes leak for every form I open, the weird thing is that it started happening after upgrading to Delphi 2009, without changing the code. – Spahi

If that is a finite amount, then it isn't an issue, but if the user has the option to open each form multiple times, and each opening leaks an additional 20 bytes, then you have a slow, but potentially troublesome memory leak. – Courante

With a 2GB of RAM, users will have to open about 100 million forms in one session before they'll run out of physical memory because of this leak. Luckily for you, RSI will limit the amount of memory that can be leaked by user actions here :-) – Geodynamics

Every memory leak is a potential programming error and should not be dismissed so easily. Also see this: https://mcmap.net/q/116769/-are-memory-leaks-ever-ok-closed – Enyo

My point is the definition of a memory leak is nebulous. If you create an object that you want in memory the entire time the application is running, and you don't free it because it is freed on termination, then that is not a memory leak, but FastMM will report it as such, and even allows for you to list it as "expected", although that is not always easy to do if you didn't introduce the construction of the object. – Courante

Answer 3

I don't know if there are any leaks in D2009 VCL, so presuming leak is in your code, first I would check following:

• is there any array or list (because of @DynArraySetLength) created in that form that is not released when you dispose form.
• is there any function that creates and returns some object that should be freed by outside caller, and if you have that kind of function check if caller frees that object.
• if this does not reveal leak, then you should check if each object that you create in your form code, gets destroyed when you destroy the form.

Hatti

Answer 4

The last time I had a puzzling leak along these lines I looked over the raw memory of the offending object--and saw text that showed me what sort of data it was. When it says it doesn't know what sort of object it is that likely means it isn't an object in the first place--so look at dynamically allocated things, including strings.

Yacov

Answer 5

IIRC VCL had a few very small leaks like this that you can ignore without much worry. This might be one of them!? Hope somebody clarifies this point.

Jeconiah

Answer 6

I would say you have something happening in your Form OnCreate event handler that is growing a DynArray.
And that DynArray is not released at the end.
But without seeing the code and actually debugging it with FastMM, it's close to impossible to guess what's really happening.

Hyperphysical