EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Memory leaks

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
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 (EldoS Corp.)

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 (EldoS Corp.)

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.

Also by EldoS: MsgConnect
Cross-platform protocol-independent communication framework for building peer-to-peer and client-server applications and middleware components.



Topic viewed 761 times

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


Back to top

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

Got it!