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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Don Dumitru [MSFT] (dondu_at_online.microsoft.com)
Date: 04/30/04 

Date: Fri, 30 Apr 2004 14:39:42 -0700

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 

-- 
This posting is provided "AS IS" with no warranties, and confers no rights.
"Francesc Guim Bernat" <news@guim.net> wrote in message
news:c6t8ri$l45$3@godfrey.mcc.ac.uk...
> 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.
>

Relevant Pages

  • Re: [Full-disclosure] [Dailydave] What RedHat doesnt want you to know about ExecShield (without
    ... buffer overflow attacks by performing executable memory checks. ... This is not the case with ExecShield without NX. ... code execution, in the other you do not. ...
    (Full-Disclosure)
  • [NT] Defeating Microsoft Windows XP SP2 Heap Protection and DEP Bypass
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... and bypassing DEP (Data Execution Prevention). ... Buffer overrun attacks are among the most common mechanisms, or vectors, ... a long string to an input stream or control longer than the memory ...
    (Securiteam)
  • Re: [SLE] Threaded Perl
    ... > Pentium-III Hardware because if the problem is essentially memory bound ... I'm not familiar with the breakdown of execution units and how they relate ... that patterns of primary storage access (especially overall L2 and L3 ... execution patterns, access to RAM is the limiting factor. ...
    (SuSE)
  • Re: Possible evidence of performance regression for 8.1-S (vs. 7.1)
    ... But cpu and memory driven tests all seem to be about the same and the disk io differences are pretty small. ... Test execution summary: ...
    (freebsd-performance)
  • Re: Can you write code directly in CIL ???
    ... I don't care if a GC occurs during the execution of my code. ... always needs all of this memory the whole time that it is executing. ... and the CLR isn't going to care what your function is doing. ... >>> You don't understand a fundamental concept to .NET and CIL. ...
    (microsoft.public.dotnet.languages.csharp)