High memory usage with madExcept
High memory usage with madExcept
In a large Delphi 7 project (consists of > 20 DLLs + Exe; uses COM/ActiveX) I observe a big difference (> 500MB) in memory usage if i compile the binaries with or without madExcept.
See Image below.
This causes OutOfMemory Exceptions quite often, since the DLLs are sometimes linked into a .NET environment via COM and the host application is quite memory consuming itself.I also use FastMM. Without madExcept no problem occurrs.
Does anybody have observed similar problems and/or has a solution?
See Image below.
This causes OutOfMemory Exceptions quite often, since the DLLs are sometimes linked into a .NET environment via COM and the host application is quite memory consuming itself.I also use FastMM. Without madExcept no problem occurrs.
Does anybody have observed similar problems and/or has a solution?
- Attachments
-
- MemoryUsage.png (23.49 KiB) Viewed 4859 times
Re: High memory usage with madExcept
Did you accidently activate the "leak reporting" or "crash on buffer overrun/underrun" features? These consume a lot more RAM.
Re: High memory usage with madExcept
No they are both off.
But the options 'RangeChecks', 'IOChecks' and 'OverFlowChecks' are activated.
Could that possibly have an effect?
But the options 'RangeChecks', 'IOChecks' and 'OverFlowChecks' are activated.
Could that possibly have an effect?
Re: High memory usage with madExcept
No, that shouldn't make any difference.
Wait, are all those > 20 DLLs compiled with madExcept? madExcept allocates a "dummy" block of about 18MB in its initialization, which is always freed whenever an exception is raised, and then allocated again after exception handling has completed. The purpose of this behaviour is that this memory block is supposed to ensure that even if the process is running out of RAM, madExcept still has some headroom to do its job. Normally, 18MB is not a problem at all. But if you have 20+ DLLs, and if they're all compiled with the full blown madExcept logic, each of them will allocate 18MB which of course adds up to a lot of RAM overall. Would that explain the problem?
Wait, are all those > 20 DLLs compiled with madExcept? madExcept allocates a "dummy" block of about 18MB in its initialization, which is always freed whenever an exception is raised, and then allocated again after exception handling has completed. The purpose of this behaviour is that this memory block is supposed to ensure that even if the process is running out of RAM, madExcept still has some headroom to do its job. Normally, 18MB is not a problem at all. But if you have 20+ DLLs, and if they're all compiled with the full blown madExcept logic, each of them will allocate 18MB which of course adds up to a lot of RAM overall. Would that explain the problem?
Re: High memory usage with madExcept
P.S: Most of those 18MB are only *reserved*, not allocated, but they still block a part of the addressable memory range, which in 32bit is limited to 4GB.
Re: High memory usage with madExcept
Thank's a lot - that's probably the explanation.
I've counted almost thirty Modules (Exe+DLLs) loaded simultanously at run time, which add up to 30 * 18MB = 540MB.
Is there a constant in the madExcept source code (which I use for compiling the binaries) defining the "18MB".
In other words, is it possible to reduce this size? Or would you recommend against it?
I've counted almost thirty Modules (Exe+DLLs) loaded simultanously at run time, which add up to 30 * 18MB = 540MB.
Is there a constant in the madExcept source code (which I use for compiling the binaries) defining the "18MB".
In other words, is it possible to reduce this size? Or would you recommend against it?
Re: High memory usage with madExcept
It's just a safety net against problems for "out of RAM" situations. For any other situations these 18MB are useless. So I see no big problem reducing that at all.
Please look at madExcept.AllocOutOfMemoryInsurance(). Feel free to change that to whatever values you're comfortable with. There are 2 VirtualAlloc calls there: One that reserves (but doesn't allocate) a big chunk of memory (4MB), the other one truely allocates 500KB. This is done 4 times, which sumes up to 18MB.
Please look at madExcept.AllocOutOfMemoryInsurance(). Feel free to change that to whatever values you're comfortable with. There are 2 VirtualAlloc calls there: One that reserves (but doesn't allocate) a big chunk of memory (4MB), the other one truely allocates 500KB. This is done 4 times, which sumes up to 18MB.