| View previous topic :: View next topic |
| Author |
Message |
Eric Grange
Guest
|
 Posted: Fri May 13, 2005 11:03 am Post subject: MM new DLL validation suggestion |
 |
|
Verify that when a DLL leaks memory, the manager releases that memory
properly when the DLL is unloaded.
-> Duplicate MMUseMemory.pas, allocate blocks of varying sizes and do
not free them (yeah, bad)
-> Reuse/update MMValidate logic
Several MM currently do not pass that validation (even though there will
be leaked memory visible in the Task Manager, MMValidate doesn't seem to
validate correctly, when large blocks Virtual Alloc'ed blocks are leaked
from a BucketMem managed DLL f.i., it still says 'ok')
Eric
|
|
| Back to top |
|
 |
Dennis
Guest
|
| Posted: Fri May 13, 2005 11:05 am Post subject: Re: MM new DLL validation suggestion |
|
|
Hi Eric
I agree.
| Quote: | -> Duplicate MMUseMemory.pas, allocate blocks of varying sizes and do
not free them (yeah, bad)
-> Reuse/update MMValidate logic
|
Do you volunterer to build a release including this new validation?
| Quote: | Several MM currently do not pass that validation (even though there will
be leaked memory visible in the Task Manager, MMValidate doesn't seem to
validate correctly, when large blocks Virtual Alloc'ed blocks are leaked
from a BucketMem managed DLL f.i., it still says 'ok')
|
Perhaps Robert is the man to fix this validation?
Regards
Dennis
|
|
| Back to top |
|
|
Pierre le Riche
Guest
|
| Posted: Fri May 13, 2005 11:36 am Post subject: Re: MM new DLL validation suggestion |
|
|
Hi Eric,
| Quote: | Verify that when a DLL leaks memory, the manager releases that memory
properly when the DLL is unloaded.
|
That's a bug in the DLL. I would prefer to know about the memory leak rather
than the MM silently releasing the memory.
Regards,
Pierre
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Fri May 13, 2005 12:48 pm Post subject: Re: MM new DLL validation suggestion |
|
|
| Quote: | That's a bug in the DLL. I would prefer to know about the memory leak rather
than the MM silently releasing the memory.
|
Then maybe raising an exception or writing to a log would be a better
solution, I don't think having a DLL leak in another process's memory
just to potentially raise leak awareness is a good solution (and having
the MM cleanup is not very different from the OS cleaning up after a
process terminates).
Eric
|
|
| Back to top |
|
|
Robert Houdart
Guest
|
| Posted: Sat May 14, 2005 10:16 am Post subject: Re: MM new DLL validation suggestion |
|
|
Hi Eric,
| Quote: | having the MM cleanup is not very different from the OS cleaning up after
a process terminates
|
Yes, I like the idea: it allows a DLL to exit cleanly even when it's
unloaded unexpectedly.
The question is whether it's worth the extra memory; one would need to store
a list of allocated large blocks.
Robert
|
|
| Back to top |
|
|
Pierre le Riche
Guest
|
| Posted: Mon May 16, 2005 9:27 am Post subject: Re: MM new DLL validation suggestion |
|
|
Hi Robert,
| Quote: | The question is whether it's worth the extra memory; one would need to
store a list of allocated large blocks.
|
A few bytes per 64K+ block is not significant. I think it should be
relatively cheap to implement too - seeing as 99%+ of the time spent
manipulating large blocks is inside the (very slow) virtualalloc/virtualfree
calls.
Regards,
Pierre
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Tue May 17, 2005 8:31 am Post subject: Re: MM new DLL validation suggestion |
|
|
| Quote: | The question is whether it's worth the extra memory; one would need to store
a list of allocated large blocks.
|
You need only 8 bytes per large block for a doubly-linked list, which is
rather insignificant (especially when compared to the 4 byte overhead
per smallblocks some MMs have).
And as Pierre said, for large blocks most of the Alloc's time is spent
on VirtualAlloc (and in practice, you'll spend a whole lot more time on
page faults when accessing the VirtualAlloc'ed memory pages for the
first time).
Eric
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
