1 2 Previous Next 15 Replies Latest reply: Feb 6, 2008 9:28 AM by Gmfeinberg-Oracle RSS

    Crash in 2.3.10 when calling removeNodes -> appendNode

    604245
      We've encountered a crash/error/invalid-data in dbxml-2.3.10 with patches 1-9 applied. This is on Redhat ES 4.0. The crash happens when calling appendNode after a call to removeNodes. The crash only happens in node-based containers.

      I've reduced the crash to a simple dbxml test case, which is below:
      $ cat script

      createContainer c
      putDocument "doc" "<foo> <bar></bar> </foo>"
      removeNodes /foo/bar
      append /foo element "" "<bar></bar>"
      cquery /*
      print
      quit

      $ rm -f c; dbxml -s script
      Segmentation fault
      The crash is very temperamental, the above case is currently crashing consistently but the behavior seems to change from second to second. When not crashing, I see one of the following:

      * unrelated data from the dbxml binary showing up in cdata
      * an error message regarding invalid UTF-8

      If I had to guess, I would say there's a wild pointer being followed and evaluated as UTF-8.

      An example of several runs of the above script follows, and shows the unpredictability I'm seeing:
      $ ./crashme.sh
      <foo>  option `--%s'<bar/></foo>
      $ ./crashme.sh
      script:4: append failed, Error: nsFromUTF8: bad utf-8 encoding File: NsUtil.cpp Line: 240
      $ ./crashme.sh
      script:4: append failed, Error: nsFromUTF8: bad utf-8 encoding File: NsUtil.cpp Line: 240
      $ ./crashme.sh
      script:4: append failed, Error: checkTrailingBytes: bad utf-8 encoding File: NsUtil.cpp Line: 190
      $ ./crashme.sh
      script:4: append failed, Error: checkTrailingBytes: bad utf-8 encoding File: NsUtil.cpp Line: 190
      $ ./crashme.sh
      script:4: append failed, Error: nsFromUTF8: bad utf-8 encoding File: NsUtil.cpp Line: 345
      $ ./crashme.sh
      script:4: append failed, Error: nsFromUTF8: bad utf-8 encoding File: NsUtil.cpp Line: 240
      $ ./crashme.sh
      ./crashme.sh: line 4:  7790 Segmentation fault      ${DBXML} -s script
      In the following messages I'll post the gdb and valgrind stack traces.
        • 1. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
          604245
          gdb backtrace:

          Starting program: /usr/gdx/sbin.Linux/dbxml -s script
          [Thread debugging using libthread_db enabled]
          [New Thread -1208801600 (LWP 7746)]

          Program received signal SIGSEGV, Segmentation fault.
          [Switching to Thread -1208801600 (LWP 7746)]
          DbXml::NsNode::insertText (this=0x9d0f220, mmgr=0x668144, index=1, text=0x20, type=8, isChild=false) at NsUtil.hpp:173
          173 ret++;
          Current language: auto; currently c++
          (gdb) bt
          #0 DbXml::NsNode::insertText (this=0x9d0f220, mmgr=0x668144, index=1, text=0x20, type=8, isChild=false)
          at NsUtil.hpp:173
          #1 0x0058dacb in DbXml::NsDomElement::_moveTextNodes (this=0x9d14454, start=0x9d01d1c, target=0x9d11ed4)
          at NsDom.hpp:491
          #2 0x0058f560 in DbXml::NsDomElement::_insertNsElement (this=0x9d14454, child=0x9d11ed4, nextNode=0x0,
          itype=DbXml::nsDomInsertAppend) at NsDom.cpp:788
          #3 0x0058f93c in DbXml::NsDomElement::insertNsChild (this=0x9d14454, child=0x9d11ed4, refChild=0x0,
          itype=DbXml::nsDomInsertAppend) at NsDom.cpp:610
          #4 0x005a1f12 in DbXml::NsXDOMElement::appendChild (this=0x9d14450, newChild=0x9d11ed0) at NsXercesDom.cpp:1253
          #5 0x0051928b in DbXml::DOMContentStep::insertChildren (this=0x9d02a78, parent=0x9d14450, target=0x0,
          itype=DbXml::nsDomInsertAppend, isAppend=true) at Modify.cpp:488
          #6 0x00519825 in DbXml::AppendStep::modify (this=0x9d02a78, node=0x9d14450, context=@0xbff28840) at Modify.cpp:616
          #7 0x0051a957 in DbXml::ModifyStep::execute (this=0x9d02a78, transaction=0x0, toModify=0x9cf4488, context=@0xbff28840)
          at Modify.cpp:76
          #8 0x0051acd0 in DbXml::Modify::executeInternal (this=0x9d01f20, txn=0x0, toModify=0x9cf4488, context=@0xbff28840)
          at /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../../include/c++/3.4.5/bits/stl_iterator.h:614
          #9 0x0051d798 in DbXml::Modify::execute (this=0x9d01f20, txn=0x0, toModify=@0x9cf3810, context=@0xbff28840,
          uc=@0xbff28848)
          at /home/mdriscoll/thundarr/dbxml/dbxml-2.3.10/dbxml/build_unix/../dist/../include/dbxml/XmlValue.hpp:190
          #10 0x005039ed in DbXml::XmlModify::execute (this=0xbff28520, toModify=@0x9cf3810, context=@0xbff28840, uc=@0xbff28848)
          at XmlModify.cpp:155
          #11 0x08067fa6 in CommandException::~CommandException ()
          #12 0x080608a2 in CommandException::~CommandException ()
          #13 0x08051394 in ?? ()
          #14 0x00d85e23 in __libc_start_main () from /lib/tls/libc.so.6
          #15 0x08050475 in ?? ()
          (gdb)
          • 2. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
            604245
            valgrind log:

            ==7750== Memcheck, a memory error detector.
            ==7750== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
            ==7750== Using LibVEX rev 1732, a library for dynamic binary translation.
            ==7750== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
            ==7750== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
            ==7750== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
            ==7750== For more details, rerun with: -v
            ==7750==
            ==7750== Syscall param pwrite64(buf) points to uninitialised byte(s)
            ==7750== at 0x48E142: pwrite64 (in /lib/tls/libpthread-2.3.4.so)
            ==7750== by 0x431004A: __os_io (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42FF2D1: __memp_pgwrite (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42FF522: __memp_bhwrite (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x430B249: __memp_sync_int (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x430B86A: __memp_fsync (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42B8E83: __db_sync (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42B824D: __db_refresh (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42B834B: __db_close (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42E9926: __fop_subdb_setup (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42CD46F: __db_open (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42C7263: __db_open_pp (in /.../lib/libdb_cxx-4.5.so)
            ==7750== Address 0x4E5E558 is 560 bytes inside a block of size 8,243 alloc'd
            ==7750== at 0x40046F2: malloc (vg_replace_malloc.c:149)
            ==7750== by 0x430E08C: __os_malloc (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42D710D: __db_shalloc (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42FDC40: __memp_alloc (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x430027A: __memp_fget (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42CC185: __db_new (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42B71CC: __db_master_update (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42E97D5: __fop_subdb_setup (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42CD46F: __db_open (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x42C7263: __db_open_pp (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x424E33B: Db::open(DbTxn*, char const*, char const*, DBTYPE, unsigned, int) (in /.../lib/libdb_cxx-4.5.so)
            ==7750== by 0x40CD5E0: DbXml::DbWrapper::open(DbXml::Transaction*, DBTYPE, unsigned, int) (Transaction.hpp:58)
            ==7750==
            ==7750== Conditional jump or move depends on uninitialised value(s)
            ==7750== at 0x4912886: xercesc_2_7::XMLUTF8Transcoder::transcodeFrom(unsigned char const*, unsigned, unsigned short*, unsigned, unsigned&, unsigned char*) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x4902093: xercesc_2_7::XMLReader::xcodeMoreChars(unsigned short*, unsigned char*, unsigned) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x49007A0: xercesc_2_7::XMLReader::refreshCharBuffer() (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x487CC07: xercesc_2_7::ReaderMgr::peekNextChar() (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x4906987: xercesc_2_7::XMLScanner::scanProlog() (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x484A3BC: xercesc_2_7::IGXMLScanner::scanDocument(xercesc_2_7::InputSource const&) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x4161361: DbXml::NsSAX2Reader::parse(xercesc_2_7::InputSource const&) (NsSAX2Reader.cpp:340)
            ==7750== by 0x415CE98: DbXml::NsSAX2Reader::parse(DbXml::XmlInputStream**) (NsSAX2Reader.cpp:322)
            ==7750== by 0x40D5369: DbXml::NsParserEventSource::start() (NsSAX2Reader.hpp:335)
            ==7750== by 0x415BC8D: DbXml::NsPushEventSourceTranslator::start() (NsEvent.cpp:36)
            ==7750== by 0x40AF2F7: DbXml::Container::indexAddDocument(DbXml::NsPushEventSource*, DbXml::Document&, DbXml::UpdateContext&) (Container.cpp:681)
            ==7750== by 0x40AF894: DbXml::Container::addDocument(DbXml::Transaction*, DbXml::Document&, DbXml::UpdateContext&, unsigned) (Container.cpp:596)
            ==7750==
            ==7750== Invalid read of size 4
            ==7750== at 0x415074A: DbXml::NsDocument::getText(DbXml::nsText_t const*, bool, bool&) (NsDocument.cpp:436)
            ==7750== by 0x4157C94: DbXml::NsDomText::_getText() const (NsNode.hpp:603)
            ==7750== by 0x4157D10: DbXml::NsDomText::getNsNodeValue() const (NsDom.cpp:2106)
            ==7750== by 0x4154ABA: DbXml::NsDomElement::_moveTextNodes(DbXml::NsDomText*, DbXml::NsDomElement*) (NsDom.hpp:491)
            ==7750== by 0x415655F: DbXml::NsDomElement::_insertNsElement(DbXml::NsDomElement*, DbXml::NsDomNav*, DbXml::NsDomInsertType) (NsDom.cpp:788)
            ==7750== by 0x415693B: DbXml::NsDomElement::insertNsChild(DbXml::NsDomNode*, DbXml::NsDomNode*, DbXml::NsDomInsertType) (NsDom.cpp:610)
            ==7750== by 0x4168F11: DbXml::NsXDOMElement::appendChild(xercesc_2_7::DOMNode*) (NsXercesDom.cpp:1253)
            ==7750== by 0x40E028A: DbXml::DOMContentStep::insertChildren(xercesc_2_7::DOMNode*, xercesc_2_7::DOMNode*, DbXml::NsDomInsertType, bool) const (Modify.cpp:488)
            ==7750== by 0x40E0824: DbXml::AppendStep::modify(xercesc_2_7::DOMNode*, DbXml::XmlQueryContext&) const (Modify.cpp:616)
            ==7750== by 0x40E1956: DbXml::ModifyStep::execute(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (Modify.cpp:76)
            ==7750== by 0x40E1CCF: DbXml::Modify::executeInternal(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (stl_iterator.h:614)
            ==7750== by 0x40E4797: DbXml::Modify::execute(DbXml::Transaction*, DbXml::XmlResults&, DbXml::XmlQueryContext&, DbXml::XmlUpdateContext&) const (XmlValue.hpp:190)
            ==7750== Address 0x4F8D650 is 8 bytes after a block of size 40 alloc'd
            ==7750== at 0x40046F2: malloc (vg_replace_malloc.c:149)
            ==7750== by 0x411188A: DbXml::SimpleMemoryManager::allocate(unsigned) (Globals.cpp:67)
            ==7750== by 0x4176A94: reallocTextList(xercesc2_7::MemoryManager*, DbXml::nsTextList*) (NsNode.cpp:541)
            ==7750== by 0x4178241: DbXml::NsNode::addText(xercesc_2_7::MemoryManager*, DbXml::nsTextList*, void const*, unsigned, unsigned, bool, bool) (XPath2MemoryManager.hpp:357)
            ==7750== by 0x415CD2A: DbXml::NsHandlerBase::addText(void*, unsigned, unsigned, bool, bool) (NsHandlerBase.cpp:175)
            ==7750== by 0x416D9C7: DbXml::NsTransientDomBuilder::characters(unsigned short const*, unsigned, bool, bool) (NsTransientDomBuilder.cpp:191)
            ==7750== by 0x415DE8A: DbXml::NsSAX2Reader::docCharacters(unsigned short const*, unsigned, bool) (NsSAX2Reader.cpp:491)
            ==7750== by 0x4854CD0: xercesc_2_7::IGXMLScanner::sendCharData(xercesc_2_7::XMLBuffer&) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x48581D7: xercesc_2_7::IGXMLScanner::scanCharData(xercesc_2_7::XMLBuffer&) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x484B7C2: xercesc_2_7::IGXMLScanner::scanContent() (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x484A3ED: xercesc_2_7::IGXMLScanner::scanDocument(xercesc_2_7::InputSource const&) (in /.../lib/libxerces-c.so.27.0)
            ==7750== by 0x4161361: DbXml::NsSAX2Reader::parse(xercesc_2_7::InputSource const&) (NsSAX2Reader.cpp:340)
            ==7750==
            ==7750== Invalid read of size 2
            ==7750== at 0x41780CD: DbXml::NsNode::insertText(xercesc_2_7::MemoryManager*, unsigned, unsigned short const*, unsigned, bool) (NsUtil.hpp:173)
            ==7750== by 0x4154ACA: DbXml::NsDomElement::_moveTextNodes(DbXml::NsDomText*, DbXml::NsDomElement*) (NsDom.hpp:491)
            ==7750== by 0x415655F: DbXml::NsDomElement::_insertNsElement(DbXml::NsDomElement*, DbXml::NsDomNav*, DbXml::NsDomInsertType) (NsDom.cpp:788)
            ==7750== by 0x415693B: DbXml::NsDomElement::insertNsChild(DbXml::NsDomNode*, DbXml::NsDomNode*, DbXml::NsDomInsertType) (NsDom.cpp:610)
            ==7750== by 0x4168F11: DbXml::NsXDOMElement::appendChild(xercesc_2_7::DOMNode*) (NsXercesDom.cpp:1253)
            ==7750== by 0x40E028A: DbXml::DOMContentStep::insertChildren(xercesc_2_7::DOMNode*, xercesc_2_7::DOMNode*, DbXml::NsDomInsertType, bool) const (Modify.cpp:488)
            ==7750== by 0x40E0824: DbXml::AppendStep::modify(xercesc_2_7::DOMNode*, DbXml::XmlQueryContext&) const (Modify.cpp:616)
            ==7750== by 0x40E1956: DbXml::ModifyStep::execute(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (Modify.cpp:76)
            ==7750== by 0x40E1CCF: DbXml::Modify::executeInternal(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (stl_iterator.h:614)
            ==7750== by 0x40E4797: DbXml::Modify::execute(DbXml::Transaction*, DbXml::XmlResults&, DbXml::XmlQueryContext&, DbXml::XmlUpdateContext&) const (XmlValue.hpp:190)
            ==7750== by 0x40CA9EC: DbXml::XmlModify::execute(DbXml::XmlResults&, DbXml::XmlQueryContext&, DbXml::XmlUpdateContext&) const (XmlModify.cpp:155)
            ==7750== by 0x8067FA5: (within /usr/gdx/sbin.Linux/dbxml)
            ==7750== Address 0x0 is not stack'd, malloc'd or (recently) free'd
            ==7750==
            ==7750== Process terminating with default action of signal 11 (SIGSEGV)
            ==7750== Access not within mapped region at address 0x0
            ==7750== at 0x41780CD: DbXml::NsNode::insertText(xercesc_2_7::MemoryManager*, unsigned, unsigned short const*, unsigned, bool) (NsUtil.hpp:173)
            ==7750== by 0x4154ACA: DbXml::NsDomElement::_moveTextNodes(DbXml::NsDomText*, DbXml::NsDomElement*) (NsDom.hpp:491)
            ==7750== by 0x415655F: DbXml::NsDomElement::_insertNsElement(DbXml::NsDomElement*, DbXml::NsDomNav*, DbXml::NsDomInsertType) (NsDom.cpp:788)
            ==7750== by 0x415693B: DbXml::NsDomElement::insertNsChild(DbXml::NsDomNode*, DbXml::NsDomNode*, DbXml::NsDomInsertType) (NsDom.cpp:610)
            ==7750== by 0x4168F11: DbXml::NsXDOMElement::appendChild(xercesc_2_7::DOMNode*) (NsXercesDom.cpp:1253)
            ==7750== by 0x40E028A: DbXml::DOMContentStep::insertChildren(xercesc_2_7::DOMNode*, xercesc_2_7::DOMNode*, DbXml::NsDomInsertType, bool) const (Modify.cpp:488)
            ==7750== by 0x40E0824: DbXml::AppendStep::modify(xercesc_2_7::DOMNode*, DbXml::XmlQueryContext&) const (Modify.cpp:616)
            ==7750== by 0x40E1956: DbXml::ModifyStep::execute(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (Modify.cpp:76)
            ==7750== by 0x40E1CCF: DbXml::Modify::executeInternal(DbXml::Transaction*, DbXml::Value*, DbXml::XmlQueryContext&) const (stl_iterator.h:614)
            ==7750== by 0x40E4797: DbXml::Modify::execute(DbXml::Transaction*, DbXml::XmlResults&, DbXml::XmlQueryContext&, DbXml::XmlUpdateContext&) const (XmlValue.hpp:190)
            ==7750== by 0x40CA9EC: DbXml::XmlModify::execute(DbXml::XmlResults&, DbXml::XmlQueryContext&, DbXml::XmlUpdateContext&) const (XmlModify.cpp:155)
            ==7750== by 0x8067FA5: (within /usr/gdx/sbin.Linux/dbxml)
            ==7750==
            ==7750== ERROR SUMMARY: 7 errors from 4 contexts (suppressed: 26 from 1)
            ==7750== malloc/free: in use at exit: 3,914,527 bytes in 4,850 blocks.
            ==7750== malloc/free: 10,730 allocs, 5,880 frees, 5,566,938 bytes allocated.
            ==7750== For counts of detected errors, rerun with: -v
            ==7750== searching for pointers to 4,850 not-freed blocks.
            ==7750== checked 1,516,240 bytes.
            ==7750==
            ==7750== LEAK SUMMARY:
            ==7750== definitely lost: 82,430 bytes in 10 blocks.
            ==7750== possibly lost: 3,208,641 bytes in 1,262 blocks.
            ==7750== still reachable: 623,456 bytes in 3,578 blocks.
            ==7750== suppressed: 0 bytes in 0 blocks.
            ==7750== Rerun with --leak-check=full to see details of leaked memory.
            Segmentation fault
            • 3. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
              Gmfeinberg-Oracle
              Mike,

              Thanks for posting the detailed information. I've been looking at the other crash (removeNodes) you posted, and know why it's crashing, but haven't yet created a suitable fix. This one is probably closely related, so I'll consider them together.

              Regards,
              George
              • 4. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                604245
                Thanks for the update!

                Last Friday we got our support login sorted out, and opened an SR for each issue, 6567732.993 and 6567730.993 . Feel free to move any discussion or updates to those SRs if you prefer.
                • 5. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                  Gmfeinberg-Oracle
                  Mike,

                  I've sent you a patch via direct email (I hope). Let me know how it goes. If all goes well, I'll do more qualification on it and it'll end up in the patch list. I'm also thinking of making a single, unified all-patches-rolled-into-one patch for 2.3, now that the list is a bit lengthy.

                  George
                  • 6. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                    533644
                    George,

                    May I please inquire whether this patch is publicly available yet. I think I've encountered the same problem.

                    Sincerely,

                    Bill
                    • 7. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                      Gmfeinberg-Oracle
                      Bill,

                      Do you have all of the public patches applied?

                      George
                      • 8. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                        620990
                        Is there already an update to this request. We've here an
                        addAppendStep that crashes non-deterministically (about every 2 weeks).

                        When I start my app with MALLOC_CHECK_=2, however, I
                        get deterministic crashes with our action under suspicion,
                        whose stack traces look similar as the one given above
                        (as you see, we're using the perl binding):

                        #0 0x00002aeeb4972aa5 in raise () from /lib64/libc.so.6
                        #1 0x00002aeeb4973e60 in abort () from /lib64/libc.so.6
                        #2 0x00002aeeb49ae3a0 in malloc_printerr () from /lib64/libc.so.6
                        #3 0x00002aeeb59ea04f in DbXml::SimpleMemoryManager::deallocate (this=0x2aeeb5c85d00, p=0x2ec1740)
                        at Globals.cpp:72
                        #4 0x00002aeeb5a5cc3b in DbXml::NsNid::getBetweenNid (this=0x2ebec90, mmgr=0x2aeeb5c85d00,
                        prev=0x2ec22c8, next=0x0, itype=2) at NsNid.cpp:215
                        #5 0x00002aeeb5a37600 in DbXml::NsDomElement::_attachToTree (this=0x2ebee68, parent=0x2ec5968,
                        previous=0x2ebb128, next=0x0, preceding=0x2ec22c8, following=0x0, itype=DbXml::nsDomInsertAppend)
                        at NsDom.cpp:1105
                        #6 0x00002aeeb5a38633 in DbXml::NsDomElement::_insertNsElement (this=0x2ec5968, child=0x2ebee68,
                        nextNode=0x0, itype=DbXml::nsDomInsertAppend) at NsDom.cpp:830
                        #7 0x00002aeeb5a38db8 in DbXml::NsDomElement::insertNsChild (this=0x2ec5968, child=0x2ebee68,
                        refChild=0x0, itype=DbXml::nsDomInsertAppend) at NsDom.cpp:611
                        #8 0x00002aeeb5a4f73a in DbXml::NsXDOMElement::appendChild (this=0x2ec5960, newChild=0x2ebee60)
                        at NsXercesDom.cpp:1253
                        #9 0x00002aeeb59b710d in DbXml::DOMContentStep::insertChildren (this=0x2e8ce00, parent=0x2ec5960,
                        target=0x0, itype=DbXml::nsDomInsertAppend, isAppend=true) at Modify.cpp:448
                        #10 0x00002aeeb59b7659 in DbXml::AppendStep::modify (this=0x2e8ce00, node=0x2ec5960, context=@0x2e48600)
                        at Modify.cpp:611
                        #11 0x00002aeeb59ba4af in DbXml::ModifyStep::execute (this=0x2e8ce00, transaction=0x2e41370,
                        toModify=0x2eb7360, context=@0x2e48600) at Modify.cpp:76
                        #12 0x00002aeeb59ba8b6 in DbXml::Modify::executeInternal (this=0x2e62080, txn=0x2e41370,
                        toModify=0x2eb7360, context=@0x2e48600) at Modify.cpp:672
                        #13 0x00002aeeb59ba9e4 in DbXml::Modify::execute (this=0x2e62080, txn=0x2e41370, toModify=@0x2e9b550,
                        context=@0x2e48600, uc=@0x2e778b0) at Modify.cpp:892
                        #14 0x00002aeeb599fadc in DbXml::XmlModify::execute (this=0x2e62060, txn=@0x2e3b790,
                        toModify=@0x2e9b550, context=@0x2e48600, uc=@0x2e778b0) at XmlModify.cpp:171
                        #15 0x00002aeeb5605c69 in XS_XmlModify__execute2 (my_perl=<value optimized out>,
                        cv=<value optimized out>) at DbXml.xs:2850
                        #16 0x0000000000482cf2 in Perl_pp_entersub ()
                        #17 0x000000000046515e in Perl_runops_debug ()
                        #18 0x00000000004249c4 in perl_run ()
                        • 9. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                          620990
                          As an aside: I get the same kind of error when deploy none but the first five patches. So, this seems not to be related to patch 7.

                          Michael
                          • 10. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                            620990
                            I think, I have found an off-by-one that might be a trigger
                            for some of this strange behaviour.

                            After fixing that,
                            at least MALLOC_CHECK and valgrind stopped barking (at least
                            this is true for me).

                            The bug (and the fix) isn't very sophisticated, so here just
                            the patch. (The off-by-one hurts a few lines below at "dest[maxlen] = 0;")

                            Best regards,
                            Michael Mirold

                            =================

                            diff -rup dbxml-2.3.10/dbxml/src/dbxml/nodeStore/NsNid.cpp dbxml-2.3.10-orig/dbxml/src/dbxml/nodeStore/NsNid.cpp
                            --- dbxml-2.3.10/dbxml/src/dbxml/nodeStore/NsNid.cpp 2006-11-01 00:39:52.000000000 +0100
                            +++ dbxml-2.3.10-orig/dbxml/src/dbxml/nodeStore/NsNid.cpp 2008-02-02 01:10:35.741294571 +0100
                            @@ -185,7 +185,7 @@ NsNid::getBetweenNid(MemoryManager *mmgr
                            xmlbyte_t *dest;
                            if (maxlen > NID_BYTES_SIZE) {
                            dest = (xmlbyte_t*)mmgr->
                            - allocate(maxlen * sizeof(xmlbyte_t));
                            + allocate(maxlen * sizeof(xmlbyte_t) + 1);
                            nidStore.nidPtr = dest;
                            } else {
                            dest = nidStore.nidBytes;
                            • 11. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                              Gmfeinberg-Oracle
                              Michael,

                              That is a new/not known problem and there is no existing patch for it except for yours, which appears correct.

                              Thanks!

                              George
                              • 12. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                                620990
                                Btw, after installing this patch, Mike's test case doesn't seem to crash dbxml any longer.
                                Can anyone confirm this?

                                Michael
                                • 13. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                                  Gmfeinberg-Oracle
                                  Michael,

                                  Are you referring to the patch that was sent to "mikecd" that is not public at this time or to the one you posted?

                                  Both solve their respective problems. Are you still seeing crashes?

                                  Regards,
                                  George
                                  • 14. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
                                    620990
                                    I refer to the crash that was posted by Mike.

                                    I was able to reproduce the behavior that he mentioned (using his dbxml script)
                                    with the "official version" , i.e. after I had applied the official patches 1-9.

                                    Interestingly, his test case didn't seem to crash a build of dbxml
                                    where only patches 1-5 were applied (so I concluded that one of the
                                    patches (most likely path 7) had an unpleasant side effect).

                                    Since I don't have the inofficial patch at hand (that was sent to mikecd), I
                                    could only reevaluate mike's test case with "my" patch and noticed that
                                    the crash has also disappeared, which, at first sight, might be an indication
                                    that the inofficial patch didn't fix the "root cause".

                                    However, with these heap errors, you never know.
                                    1 2 Previous Next