"Run-Time Check Failure #2" on Xerces & Xalan (Bug?)

[Francesc Guim Bernat]

Dear colleagues,

i'm getting in troubles using one XML library with Visual Studio .NET
and Xerces with Xalan.
When i execute the code i get the next run time error:

"Run-Time Check Failure #2 - Stack around the variable 'resolver' was
corrupted."

Looking on internet i've seen that the compiler, if you're running your
code in debug mode and you have activated the compile option /CRTs, adds
the hexadecimal sequence "cc cc cc cc cc cc cc cc" in memory just before
and after each variable in order to check if one of these bytes have
been modified after the excution.
If i not wrong, i understood that the error that i've showed is
triggered if the VC see that one of these "cc*" sequence have been
modified, coz it would mean that some part of the code has modified this
address, which would be a wrong behaivour.
Looking on the hexadecimal memory values of each variable, i've seen
that the sequences of "cc*" are modified for the variable "theEvaluator"
at the end the execution (this inspection has been done carefully of all
values that are near to the variable "resolve").
This change is done when the declaration of "XPathEvaluator
theEvaluator;" is executed.

The next lines are the important part code that generates the error:

LISTMSG XMLeanDBStatisticMsg::selectMsgs(char* selector)
{

LISTMSG llista;

XPathEvaluator::initialize();

XalanSourceTreeDOMSupport theDOMSupport;
this->document->normalize();

XercesParserLiaison * Liasion = new XercesParserLiaison();

XalanDocument* proxyDocument;
XalanNode* xalContextNode ;

XalanNode * node_porqueria = xalContextNode;

try
{
proxyDocument = Liasion->createDocument(this->document);
xalContextNode = proxyDocument->getDocumentElement();
}
catch(XalanDOMException& error)
{
return llista;
}

XPathEvaluator theEvaluator;
XalanDocumentPrefixResolver resolver(proxyDocument); /* <----- the
variable that triggers the run-time error */


try
{
XalanDOMString f = xalContextNode->getNodeName();
....
...

At the end of the email i show the hexadecimal values of the variables
taken after and before the "resolve" variable in the memory, before and
after the execution, and some detailed explanations.
If i compile the code without the /CRTs flag a error is also get.

If anyone can orient me on how can i solve the problem i would be soo
thankul. What i'm doing wrong ? it would be a bug of the libraries ? or
may be i'm looking something in a wrong way ?

cheers !

Francesc Guim Bernat


************************************************** EXTRA INFORMATION ***

- Variable theEvalutaor:

Address: 0x0012FD78
size : 16

Memory dump just when it's declared:


cc cc cc cc cc cc cc cc
0x0012FD78 38 6d 3b 00 30 7b 3b 00 00 6f 3b 00 78 6f 3b 00 cc cc cc cc
cc cc cc cc cc cc cc
(the two sequences of cc cc cc cc cc cc cc cc are present)

Memory dump after the execution:


00 00 00 00 00 00 00 00
0x0012FD78 38 6d 3b 00 30 7b 3b 00 00 6f 3b 00 78 6f 3b 00 cc cc cc cc
cc cc cc cc cc cc cc

as can be seen now the "cc cc cc cc cc cc cc cc" has been changed for
"00 00 00 00 00 00 00 00", this value is changed when the line :
"XalanDocumentPrefixResolver resolver(proxyDocument)" is executed, it
seems like if the declaration would be overlapping the previous
declaration, because if you add 36 at the address of resolver the
computed address is 0x0012FD82 that and is overlaping the variable
theEvaluator !

- Variable resolver:

Address: 0x0012FD4C
size: 36

Memory dump just when it's declared:


cc cc cc cc cc cc cc cc
0x0012FD4C fc 17 11 10 70 70 cc cc 10 aa 3b 00 d0 a9 3b 00 00 cc cc cc
02 00 00 00 70 cc cc
0x0012FD67 cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 6d 3b
00 30 7b 3b 00 00 6f
0x0012FD82 3b 00 78 6f 3b 00 cc cc cc cc cc cc cc cc

(the two sequences of cc cc cc cc cc cc cc cc are present)

Memory dumo after the execution:


cc cc cc cc cc cc cc cc
0x0012FD4C 28 13 10 10 70 70 cc cc 00 00 00 00 00 00 00 00 00 cc cc cc
00 00 00 00 70 cc cc
0x0012FD67 cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 6d 3b
00 30 7b 3b 00 00 6f
0x0012FD82 3b 00 78 6f 3b 00 cc cc cc cc cc cc cc cc cc cc

- Variable node_porqueria:

Address: 0x0012FD40
Size: 4

Memory dump just when it's declared:


cc cc cc cc cc cc cc cc
0x0012FD40 e0 70 3b 00 cc cc cc cc cc cc cc cc

(the two sequences of cc cc cc cc cc cc cc cc are present)

Memory dump after the execution:


cc cc cc cc cc cc cc cc
0x0012FD40 e0 70 3b 00 cc cc cc cc cc cc cc cc

All the size have been taken through the debuger.

 

[Don Dumitru [MSFT]]

I don't use the Visual Studio IDE's integrated debugger very much (I'm a
windbg fan - http://www.microsoft.com/whdc/devtools/debugging/default.mspx),
but my impression is that it does support "data breakpoints". These are
breakpoints which use the CPU's hardware debugging support to monitor memory
locations for access, and break if/when the memory is accessed. You can set
data breakpoints for read/write access, or for write access (and for more
esoteric things like execute access, but that doesn't apply here).

What I would suggest is that you set a normal breakpoint after the
"theEvalutaor" variable is declared, and find the memory address which you
think will get modified. Then place a data breakpoint on that memory
address, and let the program continue running. The program should then
break on the assembly language CPU instruction which is actually doing the
overwrite of the memory.

And then, given adequate symbols and source code for whatever code is
actually causing the overwrite, you can look at the call stack and the code,
and you should be able to figure out what is happening.

--Don