Memory Leak reported by FastMM5 with no list to source code

[Robert Gilland 5]

I am using Delphi 10.2 with FastMM5

 

I am getting lots of memory leaks reported with no reference to an actual line of code.

I have put an example below,  Where should I look to removed these leakkages?

 

Kind Regards,

 

Robert.

 

--------------------------------2025-07-03 13:59:58--------------------------------
A memory block has been leaked. The size is: 24

This block was allocated by thread 0x6F18, and the stack trace (return addresses) at the time was:
004239D2 [FastMM5.pas][FastMM5][FastMM_DebugGetMem$qqri][7651]
004074CA [System.pas][System][@GetMem$qqri][4749]
0040C257 [System.pas][System][@NewUnicodeString$qqri][24629]
0040C488 [System.pas][System][@UStrFromPWCharLen$qqrr20System.UnicodeStringpbi][25307]
0040C55F [System.pas][System][InternalUStrFromPCharLen$qqrr20System.UnicodeStringpcii][25484]
750A9F4B [Unknown function at ]
771AA57D [Unknown function at LdrLoadAlternateResourceModuleEx]
771C1C11 [RtlLoadString]
771A672F [LdrpResGetMappingSize]
771E9558 [Unknown function at RtlRcuSynchronize]
771AAA68 [Unknown function at RtlPcToFileHeader]
771A672F [LdrpResGetMappingSize]
771E9558 [Unknown function at RtlRcuSynchronize]
771AAA68 [Unknown function at RtlPcToFileHeader]
750A9F4B [Unknown function at ]
771AA57D [Unknown function at LdrLoadAlternateResourceModuleEx]
771AEDC7 [Unknown function at RtlReleaseSRWLockShared]
771AF1F8 [Unknown function at RtlReleaseSRWLockShared]
74EC2F2E [GetUserOverrideWord]
74EC7494 [GetLocaleInfoHelper]

The block is currently used for an object of class: UnicodeString

The allocation number is: 576361

Current memory dump of 32 bytes starting at pointer address 13FE1540:
B0 04 02 00 01 00 00 00 05 00 00 00 43 00 4F 00 53 00 53 00 4D 00 00 00 F3 2A A1 88 D2 39 42 00
.  .  .  .  .  .  .  .  .  .  .  .  C  .  O  .  S  .  S  .  M  .  .  .  .  *  .  .  .  9  B  .

[Kas Ob. 142]

7 hours ago, Robert Gilland said:

Where should I look to removed these leakkages?

This is one those that really bite.

 

I don't have a concrete answer but lets handle this step by step,

 

The stack trace (calls) is short, so i would suggest to increase it, there is 20 calls and it is not enough to go back, only the last 5 belong to your application, even the last two belong to FastMM5, and the named and relevant 3 are in the RTL not even your code, these 3 say very little as they are just converting or extracting string, they are doing the allocating, before that there is 15 calls

 

Of these 15 call we see that the calls with addresses start with 77 and 74 are definitely comes form OS dlls, but these recorded two are a concern to me  

750A9F4B [Unknown function at ]
750A9F4B [Unknown function at ]

this looks like recursive !

 

also the whole LdrLoadAlternateResourceModuleEx calling the above then leading to another loop just the same then landing at Delphi string handling code is strange the least.

 

Suggestions;

1) Increase the default stack call entries in FastMM5 ffrom 20 to may be 64 see, if that help in showing more information, we need source of this recursive calls, i don't use FastMM5 but looking at the repository the adjustment should be here https://github.com/pleriche/FastMM5/blob/master/FastMM5.pas#L1166-L1168

2) The whole thing is loading resources, namely form already loaded module (binary file being EXE or DLL..), so it is highly possible the problem sits in wrong handling WideString, WideString is not Delphi string it is different beast from UnicodeString, RTL should handling this behind the scene unless you are invoking something in wrong way or forcing resource loading by directly calling some API with wrong declaration between WideString and string.

3) the Enigma for me is this address "750A9F4B" , use what ever you can within the debugger, alas Delphi debugger is half useless and short in many places like this exact case, it might skip these OS calls in its stack trace window, rendering the use of break points and step into in the CPU window harder than usual, anyway try to find out who own that address, from what i see most likely it is a BPL and you are using it, also it doesn't have debug info, so you must pinpoint it.

 

step 3 is crucial to understand how this happen and what went wrong, this is the one that tried to load/extract some null-terminated string from resource within a module then recursively called for the conversion into Delphi string.  

 

And good luck !

[Stefan Glienke 2142]

Looking at the string contents should give a pointer as to where they come from. For example, the one you showed is a 5-character-long string "COSSM"