I take it then, that if you remove the calls to
XMLPlatformUtils::Initialize() and XMLPlatformUtils::Terminate(), and you
don't load your extension DLL,  the memory leaks aren't present? 

Presumably, you downloaded the Xerces DLL - you didn't build it - so can you
verify that the runtime library being used by the Debug configurations for
both your application and your extension DLL is the Debug Multithreaded DLL
version? (Project Settings | C/C++ tab | Code Generation Category, for each
project.)

Just to get a better idea of the environment, what type of EXE is your
application (MFC-Appwizard EXE, Win32 Exe, console EXE, console EXE with MFC
support...)?

Perhaps you should check into _CrtSetAllocHook() and/or _CrtSetDebugBreak()
(or something approaching that name - I can't recall  it exactly).
Those allocation IDs look rather low (45, 46, 47, 48 )...  Does your
application use any other DLLs that you wrote?  Anyways, in order to get the
results from those _CrtSet.... functions, you may need to call them prior to
main() or whatever your entry-point is in the EXE.  The _CrtSetAllocHook
function gives you the allocation ID - perhaps you can see what the ID is
when your hook function is called the first time - if it is higher than the
allocation IDs, you will need to find a way to call the _CrtSet... much
earlier in your program's execution.  You could create a cheesy class and
instantiate a global object of that type, and call the _CrtSet...
function(s) in its initialization.  However, if your EXE implicitly loads
other DLLs (perhaps some you wrote), and any allocations are made from those
DLLs, it may be pushing the allocation ID well over 45, 46, 47, 48 even
before the code in the actual EXE starts to be executed.  In this case, if
you can determine which DLL those allocations are taking place in, and you
have the source for that DLL, you could potentially modify that DLL in a
manner similar to the one described above, to pinpoint the allocations and
then potentially determine why the memory isn't being deallocated.

The above method might help diagnose the initial memory leaks you are
seeing.

With regards to your statement that "I get a lot more memory-leaks (more
than 3000 ...) when I do some SAX-parsing (similar to the
SAX2COUNT-sample"...  Can you comment out the installation of your handler
object into the parser (it's been a while and I don't have access to the
docs, but it's something like "parser->setHandler" or
"parser->setDocumentHandler")?  If the memory leaks go away when you comment
this line out, the problem is likely somewhere in your handler.

Hope something helped...

Erik

-----Original Message-----
From: Ing. Hans Pesata
To: Xerces Mailinglist
Sent: 8/4/01 10:28 AM
Subject: problems with Xerces 1.5.1 within MFC-app

Hi !

I am trying to use the Xerces 1.5.1 Dll within a MFC-app but I am
running
into
some troubles with memory-leaks.

I am using NT Workstation 4.0/SP6, VC++ 6.0 and my app dynamically links
MFC.

I added XMLPlatformUtils::Initialize() to the InitInstance()-member
of my CWinApp-derived class and XMLPlatformUtils::Terminate() to the
ExitInstance()-member.

When I start my app without doing any parsing I get the following
debug-output after terminating it:

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 am using the parser within an MFC-extension-Dll which I dynamically
load
from within my app
and I get a lot more memory-leaks (more than 3000 ...) when I do some
SAX-parsing (similar to the SAX2COUNT-sample)
within a function of this Dll. I am using a DTD for the validation of my
XML-file.

I also tried to use XMLPlatformUtils::Initialize() /
XMLPlatformUtils::Terminate() calls within the
extension-Sll, but it was always the same.

I tried the stable 1.5.1 build from 18.07.2001 and also the one from
30.07.2001 but it is the same.

I dont know how to proceed with this, any help with this would be
greatly
appreciated,
thanx in advance!

Regards,
Hans Pesata


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to