"Antonio Da Silva" wrote:
: :
> D:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\crtdbg.h(552) : {892}
> normal block at 0x007DBD80, 2 bytes long.
> Data: <C > 43 00
: :
> Have some one any idea?
Antonio, since Xerces is input-driven, it's unlikely this information
alone is enough to track down the memory leak without your input
document and source code.
What you can do to get more information after having received this
dump from Visual C++'s Crt heap debugger is to set a breakpoint on
one of these memory allocations, and then look up the call stack to
see where in Xerces these 2-byte allocations are taking place.
Ideally, everytime you run your application with the same control
flow and input document to parse, with the same other applications
in memory, you should get exactly the same object dump.
If so, then what you should do is add this someplace near the begin-
ning of your program (you've probably already included crtdbg.h):
// Set breakpoint on 892nd memory allocation.
_CrtSetBreakAlloc( 892);
Then, next time you run the program under the debugger, a break
point should fire when an allocation that is getting leaked (notice
the number in curly braces from the dump, this is the heap debug-
ger's sequential allocation number) occurs. You can call up the
Call Stack window or the drop-down listbox near the watches
and see which Xerces DOM method is reponsible.
If you can back track the request to the offending memory alloc
in Xerces, please let us know.
Derek Harmon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
