Run-Time Check Failure #2 using XPath with Xalan and Xerces

[Francesc Guim Bernat]

Dear colleagues,

i'm getting in troubles using one XML library with Visual Studio .NET
and Xerces with Xalan. (Xercer 2.4 and Xalan 1.7)
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 ;


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



All the size have been taken through the debuger.