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

Discussion in 'XML' started by Francesc Guim Bernat, Apr 30, 2004.

  1. 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.
     
    Francesc Guim Bernat, Apr 30, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Volker Jordan

    Xpath apache xerces/xalan dom3

    Volker Jordan, Jan 22, 2004, in forum: XML
    Replies:
    0
    Views:
    545
    Volker Jordan
    Jan 22, 2004
  2. cvissy
    Replies:
    0
    Views:
    609
    cvissy
    Nov 16, 2004
  3. Francesc Guim Bernat
    Replies:
    1
    Views:
    440
    Christopher Benson-Manica
    Apr 30, 2004
  4. Antony
    Replies:
    8
    Views:
    620
    Jim Langston
    Feb 9, 2006
  5. PH.D.Condidater.Li.Ning

    Help for the anoying 'Run-Time Check Failure #3'

    PH.D.Condidater.Li.Ning, Nov 12, 2007, in forum: C++
    Replies:
    1
    Views:
    648
    Alf P. Steinbach
    Nov 12, 2007
Loading...

Share This Page