Need help with HEAP CORRUPTION and my MSVC 6 DLL
I have a MSVC 6 DLL that I've written. It is used heavily by a Delphi 6 app
I've written.
For two months everything has been working fine. Then I changed some things
in the code recently, and now I'm getting what looks like severe corruption
of the heap.
I am wondering if it is some strange interaction between the Delphi app and
my MSVC 6 DLL, that I somehow caused with a recent change to either of the
programs. I say this because when I run the exact same library code that is
"wrapped" in the DLL, in a Win32 Console test application which I created to
test the code, it works perfectly. It is only, and only recently, when I
run it as a DLL with the Delphi app as a client, that I see the heap
corruption. I checked all the project settings for the dependent libraries
my DLL links in, and my DLL project settings, and everyone is set to Debug
Multithreaded DLL for the code generation option (and all other settings are
the same too). I am currently testing in Win32 Debug configuration with
gflags monitoring the process in "/full" mode.
I say the heap is corrupted because of the following evidence:
- There is a setup function in the DLL code where a large amount of
calloc()'s occur in a loop. Each calloc() does one allocation of a 12 byte
elements (i.e. 12 bytes total). Normally this only consumes a couple of
megabytes of memory and executes fast. I traced through the calloc() calls
and with each calloc() over 4000 bytes (4k) are being allocated!. After a
few seconds. the memory consumption of the process as reported by the Win2k
task manager, shoots up to almost 280 megabytes of memory. Pretty soon
thereafter I get a "System is low on virtual memory" dialog box and finally
all calloc() calls begin to fail. Meltdown.
Before I ran gflags, I was getting weird access violations all over the
place.
As I rack my brain trying to think what I may have done recently to cause
this, the only major change I can think of was the including of <crtdbg.h>
in several source files that use "assert". But those includes are in IFDEF
blocks and are not included when I build using the Win 32 release
configuration, yet the heap corruption still occurs. This would seem to
indicate that the <crtdbg.h> change is not a factor.
Once more, this does not happen with the exact same code when that code is
linked into an MSVC Win32 Console application, only when running as a DLL.
So what can I try to do to fix this? What kind of tests can I try?
Thanks,
Robert
