Hi,
I did some debugging into these memory leaks...
In my environment, using 1.5.1, I was able to recreate the same 4 memory
leaks you were, albeit at different memory addresses, and different
allocation IDs (no big deal - this is to be expected).
Basically, I made a Dialog MFC AppWizard, and added calls to
XMLPlatformUtils::Initialize() in InitInstance, and
XMLPlatformUtils::Terminate() in ExitInstance()...
Your allocation ID 45 (my allocation ID 56):
In TraverseSchema.cpp:
XMLStringPool TraverseSchema::fStringPool;
calls, in StringPool.cpp:
fHashTable = new RefHashTableOf<PoolElem>(modulus); (new gets called to
alloc 16 bytes)
Your allocation ID 46 (my allocation ID 57):
The above, in turn, causes
RefHastTableOf.c:
fBucketList = new RefHashTableBucketElem<TVal>*[fHashModulus]; (new gets
called to alloc 436 bytes)
Your allocation ID 47 (my allocation ID 58):
That, in turn causes
RefHashTableOf.c (initialize)
to call
fHash = new HashXMLCh(); (new gets called to alloc 4 bytes)
Your allocation ID 48 (my allocation ID 59):
XMLStringPool TraverseSchema::fStringPool;
causes, in XMLStringPool::XMLStringPool
to call
fIdMap = new PoolElem*[fMapCapacity]; (new gets called to alloc 256 bytes.)
So, it would seem that the one line of code that is declaring the
XMLStringPool in TraverseSchema.cpp is "causing" all of the memory leaks
(check the Ctor for XMLStringPool, in StringPool.cpp (or see below)
XMLStringPool::XMLStringPool(const unsigned int modulus) :
fIdMap(0)
, fHashTable(0)
, fMapCapacity(64)
, fCurId(1)
{
// Create the hash table, passing it the modulus
fHashTable = new RefHashTableOf<PoolElem>(modulus);
// Do an initial allocation of the id map and zero it all out
fIdMap = new PoolElem*[fMapCapacity];
memset(fIdMap, 0, sizeof(PoolElem*) * fMapCapacity);
}
However, the memory is, in fact, deleted in the XMLStringPool Dtor
(StringPool.cpp, or see below).
XMLStringPool::~XMLStringPool()
{
delete fHashTable;
delete [] fIdMap;
}
It's just that VC++ dumps the memory leaks prior to the destructor being
invoked, and since the memory hasn't been deallocated YET, it shows up as a
memory leak. I verified this by placing a breakpoint in the XMLStringPool
Dtor. When the debugger stopped there, the dump was already present in the
Debug window in VC++.
Dumping objects ->
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {59}
normal block at 0x007C4998, 256 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {58}
normal block at 0x007C4950, 4 bytes long.
Data: <|P > 7C 50 10 12
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {57}
normal block at 0x007C2DA0, 436 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {56}
normal block at 0x007C2D48, 16 bytes long.
Data: < -| m PI| > 01 CD CD CD A0 2D 7C 00 6D 00 00 00 50 49 7C 00
Object dump complete.
In order to debug this, I had to add code to Xerces that basically created a
global object that was constructed prior to the allocations for the
allocation IDs that the debugger was reporting as being leaked. In the
constructor of my object, I called
_CrtSetAllocHook( AllocHook );
AllocHook is a Hook function for C-Runtime library allocations. AllocHook
was trivial, as I just placed a breakpoint on the entry into the function.
int AllocHook( int nAllocType, void* pUserData, size_t size, int nBlockType,
long lRequestNumber, const unsigned char*
szfilename, int nLineNumber)
{
return 1;
}
The first allocation that caused the breakpoint to hit was allocation ID 56
(your 45). At that point, it was just a matter of checking out the call
stack...
These memory leaks don't appear with 1.4.0, since 1.4.0 did not have any
schema support...
I wonder if these leaks will cause the same discussion that prompted the
addition of XMLPlatformUtils::Terminate()...
Anyone have any ideas on how to get around these false leak reports (if,
indeed, the desire is to satiate those who worry that their Favorite Tool
reports leaks...)?
-----Original Message-----
From: Ing. Hans Pesata [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 4:36 AM
To: Erik Schroeder
Subject: Xerces 1.5.1 with MFC
Hi !
sorry if I contact you directly and not via the Xerces-mailing.list,
but the problems I have with Xerces using MFC, still occur and I dont know
how to proceed.
* I just created a simple MFC-app using appwizard (MFC-appwizard exe)
* I added the appropriate headers
* added XMLPlatformUtils::Initialize() to my InitInstance()-handler
* added XMLPlatformUtils::Terminate() to my ExitInstance()-handler
* link the xerces-c_1D.lib.
starting and terminating this simple app (without doing any parsing)
still produces the following leaks:
Detected memory leaks!
Dumping objects ->
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {48}
normal block at 0x007D19C0, 256 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {47}
normal block at 0x007D1AF0, 4 bytes long.
Data: <|p > 7C 70 11 12
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {46}
normal block at 0x007D1B20, 436 bytes long.
Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {45}
normal block at 0x007D1D00, 16 bytes long.
Data: < } m } > 01 CD CD CD 20 1B 7D 00 6D 00 00 00 F0 1A 7D 00
Object dump complete.
I have the right version of the runtime-library (Debug Multithredaed Dll)
this is the default.
This memory-leaks dont appear using the xerces 1.4.0 dll.
Did you try using Xerces 1.5.1 within an MFC-app ?
Regards,
Hans Pesata
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
