Memory Leak (AnsiString) - Looking for clue(s)


I am working on an application and suddenly I get memory leaks reported for AnsiStrings which - so far I have been able to figure out are related to EntityLists and the object field referencing them.

I have an entity structure like this:

Top Level: TMaster 
First Level: TChild (1-M)
Second Level: TChildA, TChildB and TChildC (all 1-M)

Initially only had TChildA and TChildB and all was working fine.  I then added TChildC (through Data Modeler, following the same indexes and relationship setup as for TChildA and TChildB, when the problem started appearing. 

As long as I only have/input data for TMaster and TChild (2 levels), there's no problem either. However, as soon as I add data (just a single entity) for either TChildA, TChildB ** OR ** TChildC, a memory leak is reported at shutdown (ReportMemoryLeaksOnShutdown := true). Note that the number of AnsiStrings leaked is multiplied each time the TMaster and its (grand)children are processed to produce a drawing.

Using a trial version of Deleaker, I did not get very far other than that I noticed that retrieving values for TObjectField and TField (parameter = AnsiString) are involved prior to the leak(s) occurring.

I have repeatedly review the Data Model, regenerated the entire database (SQLite) and exported to classes. Also rebuilt the bpl for design time field definitions and the entire application (removed and placed new datasets etc).  

As it's currently not the time for me to make investments in leak detection/profiling software (nor do I have much experience with this), I was hoping that you have seen this issue before and that you can give me some suggestions as to where to problem may lie.  Any suggestion (even if far fetched) will be more than welcome because I am at a loss at the moment.

Thanks in advance!!


I managed to produce a FastMM dump.  This is after opening and closing the form without doing anything further (one second level child record). I have omitted the memory dump to keep this post short.

Perhaps this helps in suggesting where I could possible find the error? I can't make much sense of it (other than what I already knew).

Rgds, Mark

A memory block has been leaked. The size is: 52
This block was allocated by thread 0x21CC, and the stack trace (return addresses) at the time was:
407256 [System.pas][System][@GetMem$qqri][4830]
40A404 [System.pas][System][@NewAnsiString$qqrius][25362]
40A64F [System.pas][System][@LStrFromPCharLen$qqrr27System.%AnsiStringT$us$i0$%pcius][26097]
A0DED6 [Data.DB.pas][Data.DB][Db.TStringField.GetValue][6122]
A0DCFF [Data.DB.pas][Data.DB][Db.TStringField.GetAsVariant][6072]
A159A4 [Data.DB.pas][Data.DB][Db.TObjectField.GetFieldValue][9467]
A15A5F [Data.DB.pas][Data.DB][Db.TObjectField.GetAsVariant][9483]
D88A79 [cxDB][GetFieldValue$qqrp14Data.Db.TField]
E3BFA8 [cxDBData][TcxValueDefDBReader.GetValue]
95BCAC [cxDataStorage][TcxValueDefReader.Read]
E3BFF9 [cxDBData][TcxValueDefDBReader.Read]
The block is currently used for an object of class: AnsiString
The allocation number is: 229165

Looking closer at the memory dump (should have done that earlier), I noticed that the leaked AnsiStrings all match the values of the second level children's ID field (TGUID).

ä  .  .  .  .  .  .  .  &  .  .  .  {  A  1  8  0  3  F  7  9  -  4  C  2  5  -  4  0  5  7  -
A  9  F  F  -  6  2  A  0  5  E  8  8  F  4  4  4  }
  .  .  Ò  û  ¹  u  .  .  .  .  ±  (  Þ  }
.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  †  6  .  .  V  r  @  .  o  „  @  .  >  Œ  @  .
*** SOLVED ***
Apologies for the numerous posts on this subject, but this problem was "eating my lunch".
Luckily, by deduction, I managed to solve the issue!

I finally decided to remove everything on my form from the first child level down; Aurelius Datasets, TDataSources and grids (DevExpress TcxGrid). I then proceeded as follows;

  1. Placed back all Aurelius Datasets (hooked to relevant DatasetFields) and TData sources. No memory leaks.
  2. Placed back TcxGrid for first level (TChild). Memory leak!!!
Further investigation revealed that when creating (default) columns for the TcxGridView, columns for the nested DatasetFields are included by default.  As long as these columns are defined (even when not visible), the memory leak occurs for every entity in the nested dataset!

The solution is thus simple: do not create columns for dataset fields or remove them!!

Once more, apologies for the posts, but perhaps someone else may find it useful as a reference.


Hi Mark,

Thank you for the feedback. This is really strange, such leak shouldn't happen. Do I understand this is an issue with TcxGrid? Shouldn't it be reported back to vendor?
Pretty sure it is a TcxGrid issue.  Will definitely submit a bug report.
I'd be curious to find out if it also occurs with their new EntityFrameWork ;-)