I'm using FastMM4 in FullDebugMode to find memory leaks, and I'm getting a lot of complaints about UnicodeString
, TList
, TParameters
, etc. instances like this:
A memory block has been leaked. The size is: 276
This block was allocated by thread 0x2928, and the stack trace (return addresses) at the time was:
404CFE [System][@GetMem$qqri]
408C0F [System][@NewUnicodeString$qqri]
408E40 [System][@UStrFromPWCharLen$qqrr20System.UnicodeStringpbi]
408F17 [System][InternalUStrFromPCharLen$qqrr20System.UnicodeStringpcii]
5C006B [Vcl.Themes][Themes.TUxThemeStyle.GetElementDetails$qqr27Vcl.Themes.TThemedScrollBar]
774861EF [GetWindowLongW]
74B6588B [Unknown function at DrawThemeParentBackground]
74B6586C [Unknown function at DrawThemeParentBackground]
74B6780B [Unknown function at OpenThemeData]
7748C5FE [Unknown function at gapfnScSendMessage]
77481B31 [Unknown function at PeekMessageA]
The block is currently used for an object of class: UnicodeString
A memory block has been leaked. The size is: 20
This block was allocated by thread 0x2928, and the stack trace (return addresses) at the time was:
404CFE [System][@GetMem$qqri]
406EB3 [System][TObject.NewInstance$qqrv]
407556 [System][@ClassCreate$qqrpvzc]
406EE8 [System][TObject.$bctr$qqrv]
814DD8 [Datasnap.DBClient][Dbclient.TCustomClientDataSet.ClearActiveAggs$qqrv]
815359 [Datasnap.DBClient][Dbclient.TCustomClientDataSet.ResetAllAggs$qqro]
80D8AC [Datasnap.DBClient][Dbclient.TCustomClientDataSet.InternalOpen$qqrv]
6948D7 [Data.DB][Db.TDataSet.DoInternalOpen$qqrv]
69498F [Data.DB][Db.TDataSet.OpenCursor$qqro]
80CA87 [Datasnap.DBClient][Dbclient.TCustomClientDataSet.OpenCursor$qqro]
69484B [Data.DB][Db.TDataSet.SetActive$qqro]
The block is currently used for an object of class: TBits
My current memory leak report is about two megabytes, and most of its content is like that. What is happening? Should I be concerned about RTL
and VCL
internals and possible memory leaks within them? And, if yes, what can I do about them?
Should I be concerned about RTL and VCL internals and possible memory leaks within them?
Probably not. Recent versions of the RTL/VCL are clean. I've not encountered leaks with them, although that's not to say that you won't.
In any case, the reports you present looks just like a routine memory leak in your code. When your code leaks, typically what happens is that you create an object and then fail to destroy it. The leaked object can own lots of other objects. And they are all tracked by FastMM and reported as distinct leaks. So, if you create an object that contains a string, then leaking the owning object leaks the string too.