EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Memory Leaks in 8.0.176 VCL version

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#13548
Posted: 05/31/2010 16:32:50
by Nathan Sutcliffe (Standard support level)
Joined: 09/13/2006
Posts: 14

The following objects don't appear to be deallocated anywhere. This pattern may be repeated in other files, but these are the leaks that are affecting our application:

Win32CryptoProv in SBCryptoProvWin32.pas
BuiltInCryptoProv in SBCryptoProvBuiltIn.pas
G_DefaultManager in SBCryptoProvManager.pas
#13550
Posted: 06/01/2010 00:59:35
by Eugene Mayevski (EldoS Corp.)

This is not a leak - these objects are created once per application and are destroyed during application shutdown. Unless you have a DLL which is loaded and unloaded multiple times consequently to a host application, there's no problem with this design (and BTW no way to change it). For DLLs we have a special method which can lead to untraceable errors if used, so we don't disclose it to public.


Sincerely yours
Eugene Mayevski
#13556
Posted: 06/01/2010 10:05:36
by Nathan Sutcliffe (Standard support level)
Joined: 09/13/2006
Posts: 14

Thanks for looking into this. They're not ongoing leaks because in each case, only one object is created during execution, but I don't see any code to explicitly deallocate these objects. We like all resources to be explicitly deallocated so that FastMM4 and other profilers don't report them as leaks.

Will it cause any problem if I deallocate these objects in the finalization clauses of their respective units? If not, I guess I'll register them as "known leaks" for FastMM4.
#13557
Posted: 06/01/2010 10:27:23
by Eugene Mayevski (EldoS Corp.)

Yes, explicit disposal of these objects will cause hard to track problems in your code.


Sincerely yours
Eugene Mayevski
#13564
Posted: 06/01/2010 12:38:13
by Nathan Sutcliffe (Standard support level)
Joined: 09/13/2006
Posts: 14

OK, then could I turn this thread into a feature request? There's got to be some point during application termination that it would be appropriate for these objects to be explicitly deallocated. That would be a big help for anyone who uses memory leak checking tools.
#13568
Posted: 06/01/2010 14:07:55
by Ken Ivanov (EldoS Corp.)

You can actually call SBUtils.CleanupRegisteredGlobalObjects() method to dispose of those objects. However, you MUST ensure that no SBB components are alive when this method is called.
#13569
Posted: 06/01/2010 14:41:50
by Eugene Mayevski (EldoS Corp.)

Quote
Nathan Sutcliffe wrote:
There's got to be some point during application termination that it would be appropriate for these objects to be explicitly deallocated.


There's no such point. Though Innokentiy has revealed the method, but it's not reliable at all -- it just kills the objects, and you have all chances to kill the object earlier, than other components end up using these objects. The reason is simple -- your code (whatever code you would write) is executed before finalization section of the referenced units. And that is the place where in some cases the components can be used and referenced. Now, if you delete the objects in your code, you can get access violation on exit. The worst is that you can get an AV only on some systems or only in release build or in some other hardly reproducible way.


Sincerely yours
Eugene Mayevski
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 1237 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!