I've run into a rather large problem, I'm creating DLL projects. A new DLL
project will compile up a DLL that has a 200 byte memory leak in it. The
leak come up in Code Guard and by checking the address of the leak I can see
it occurs in the '__bormm_stub_GetMem' function. Is there a fix for this?
This is becoming a big problem. Some more info, I'm running BCB5, using the
default options in the DLL wizard, and I do need VCL support....
Please help.
John.
Hmm, never seen a leak that was 'caused' by a GetMem function...
why don't you look up the stack a bit to where you allocated
this memory, and then try to find where you're deallocating it...
HTH,
Jurko
"John" <john_at_kbs_is@hotmail.com> wrote in message
http://groups.google.com/groups?selm=3b26523f%241_1%40dnews...
> I've run into a rather large problem, I'm creating DLL projects. A new DLL
> project will compile up a DLL that has a 200 byte memory leak in it. The
> leak come up in Code Guard and by checking the address of the leak I can see
> it occurs in the '__bormm_stub_GetMem' function. Is there a fix for this?
> This is becoming a big problem. Some more info, I'm running BCB5, using the
> default options in the DLL wizard, and I do need VCL support....
>
> Please help.
>
> John.
>
>
On Tue, 12 Jun 2001 13:43:57 -0400, "John" <john_at_kbs_is@hotmail.com> wrote:
> Is there a fix for this?
Best fix I know is put breakpoints in your code
in big sections and gradually narrow down the
resource leak.. sort of like a binary search. :)
Maybe some destructor isn't freeing a resource
someplace.
Mike
--
"Only choice is an oxymoron."
--
I got rid of the memory leak by only loading the DLL once, orginaly I setup
the app to unload the DLL when the it was no longer in use and load it on
demand again later. I just remove this feature.
Thanks...
John.
There is a one time leak in the VCL that gets cleaned up by the OS. Problem is
that when you dynamically load and unload Dlls over and over again this leak
builds up with each load. This is a long standing leak in the VCL and I don't
expect it fixed soon as the fix is not simple if even doable.
John wrote:
>
> I got rid of the memory leak by only loading the DLL once, orginaly I setup
> the app to unload the DLL when the it was no longer in use and load it on
> demand again later. I just remove this feature.
>
> Thanks...
>
> John.
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Anyone who cannot cope with mathematics is not fully human.
At best he is a tolerable subhuman who has learned to wear
shoes, bathe and not make messes in the house. (Heinlein)
"Jeff Overcash (TeamB)" <overcash@onramp.net> wrote in message
http://groups.google.com/groups?selm=3B283D05.DF59E1A8%40onramp.net...
> There is a one time leak in the VCL that gets cleaned up by the OS. Problem is
> that when you dynamically load and unload Dlls over and over again this leak
> builds up with each load. This is a long standing leak in the VCL and I don't
> expect it fixed soon as the fix is not simple if even doable.
Can you point out where there is documentation on this? This is the first
I've heard of it, though I've never run into it before. I'd be curious to
read up on it.
TIA,
- Clayton
"Clayton M. Arends" wrote:
>
>
> Can you point out where there is documentation on this? This is the first
> I've heard of it, though I've never run into it before. I'd be curious to
> read up on it.
>
I'm not aware of any documentation on it. The instance block in
MakeObjectInstance is never freed. The problem is that the VCL can't guarantee
that the wndproc stubs are not still in use when the unit finalization code is
executed. This can lead to BSOD so it is safer to let the OS clean up after the
App ends. Unfortunately that also causes a slow leak if you are using Dll
without packages and constantly loading and unloading the the Dll since the
calling application has to end to have the OS reclaim the memory. This has been
around since the very first version of the VCL and since there is no safe time
to free this memory it is unlikely to see a solution in the near future.
> TIA,
>
> - Clayton
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
Anyone who cannot cope with mathematics is not fully human.
At best he is a tolerable subhuman who has learned to wear
shoes, bathe and not make messes in the house. (Heinlein)
_files/cleardot.gif) |
©2002 Google