EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Memory leaks

Posted: 04/15/2014 14:25:16
by henk ten Hove (Standard support level)
Joined: 03/28/2014
Posts: 6

Yes, I know this is in the FAQ and yes I know they can simple be ignored. But would it be an idea to register those leaks into the memory manager so they can be ignored when the application closes?

Indy has a very nice feature for that in the idGlobal unit, just register the expected leaks and be done with all those FastMM4/MadExcept/etc messages. Its a rather simple solution, would be nice for a next release.


function IndyRegisterExpectedMemoryLeak(AAddress: Pointer): Boolean;
// RLebeau 4/9/2009: the user can override the RTL's version of FastMM
// (2006+ only) with the full version of FastMM in order to enable
// advanced debugging features, so check for that first...
Result := FastMM4.RegisterExpectedMemoryLeak(AAddress);
{$IFDEF HAS_System_RegisterExpectedMemoryLeak}
// RLebeau 4/21/08: not quite sure what the difference is between the
// SysRegisterExpectedMemoryLeak() and RegisterExpectedMemoryLeak()
// functions in the System unit, but calling RegisterExpectedMemoryLeak()
// is causing stack overflows when FastMM is not active, so call
// SysRegisterExpectedMemoryLeak() instead...

// RLebeau 7/4/09: According to Pierre Le Riche, developer of FastMM:
// "SysRegisterExpectedMemoryLeak() is the leak registration routine for
// the built-in memory manager. FastMM.RegisterExpectedMemoryLeak is the
// leak registration code for FastMM. Both of these are thus hardwired to
// a specific memory manager. In order to register a leak for the
// *currently installed* memory manager, which is what you typically want
// to do, you have to call System.RegisterExpectedMemoryLeak().
// System.RegisterExpectedMemoryLeak() redirects to the leak registration
// code of the installed memory manager."

//Result := System.SysRegisterExpectedMemoryLeak(AAddress);
Result := System.RegisterExpectedMemoryLeak(AAddress);
Result := False;
Posted: 04/15/2014 14:29:33
by Eugene Mayevski (Team)

Thank you for the interesting reference, but wouldn't it be simpler for you to just call SBUtils.CleanupRegisteredGlobalObjects on application shutdown? That would actually release memory.

Sincerely yours
Eugene Mayevski
Posted: 04/16/2014 07:16:56
by henk ten Hove (Standard support level)
Joined: 03/28/2014
Posts: 6

I know about that cleanup call and we have tried that but the cleanup is crashing with a lot of AV's (not sure why, we have not investigated that any further). AFAICT there's no proper way other than to add the expected memory leaks.

Posted: 04/16/2014 07:20:57
by Vsevolod Ievgiienko (Team)

cleanup is crashing with a lot of AV's

It shouldn't. Could you please provide a small test case to reproduce the issue.
Posted: 04/16/2014 08:18:23
by henk ten Hove (Standard support level)
Joined: 03/28/2014
Posts: 6

Hello Vsevolod,

Will do, but it will take a while before i get around to it.

Posted: 04/22/2014 10:13:36
by henk ten Hove (Standard support level)
Joined: 03/28/2014
Posts: 6

Hello Vsevolod,

There are several background threads using indy SSL sockets to the server. Those are using SBB and do not expect stuff to be freed. The threads are running until the end of the application (and they are really intended to run until the end).

So i'm afraid we would be better of register those leaks as they are intended leaks.




Topic viewed 925 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!