This discussion is archived
1 2 Previous Next 15 Replies Latest reply: Feb 6, 2008 7:28 AM by gmfeinberg RSS

Crash in 2.3.10 when calling removeNodes -> appendNode

604245 Newbie
Currently Being Moderated
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 Newbie
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Journeyer
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Journeyer
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Journeyer
    Currently Being Moderated
    Bill,

    Do you have all of the public patches applied?

    George
  • 8. Re: Crash in 2.3.10 when calling removeNodes -> appendNode
    620990 Newbie
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Journeyer
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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 Journeyer
    Currently Being Moderated
    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 Newbie
    Currently Being Moderated
    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