After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 68407 - Possible problem in xmlStaticCopyNode with xmlAddChild (2.4.12)
Possible problem in xmlStaticCopyNode with xmlAddChild (2.4.12)
Status: VERIFIED FIXED
Product: libxml
Classification: Deprecated
Component: general
unspecified
Other All
: Normal major
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks:
 
 
Reported: 2002-01-10 14:43 UTC by Greg Sjaardema
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Greg Sjaardema 2002-01-10 14:43:48 UTC
I think I've found a problem in xmlStaticCopyNode.  At line 2780 of
 tree.c, there is the code:

     if (parent != NULL)
         xmlAddChild(parent, ret);

 Inside xmlAddChild is the following:

     /*
      * If cur is a TEXT node, merge its content with adjacent TEXT nodes

      * cur is then freed.
      */
     if (cur->type == XML_TEXT_NODE) {
         if ((parent->type == XML_TEXT_NODE) &&
             (parent->content != NULL)) {
 #ifndef XML_USE_BUFFER_CONTENT
             xmlNodeAddContent(parent, cur->content);
 #else
             xmlNodeAddContent(parent, xmlBufferContent(cur->content));
 #endif
             xmlFreeNode(cur);
             return(parent);
         }
         if ((parent->last != NULL) && (parent->last->type ==
 XML_TEXT_NODE) &&
             (parent->last->name == cur->name)) {
 #ifndef XML_USE_BUFFER_CONTENT
             xmlNodeAddContent(parent->last, cur->content);
 #else
             xmlNodeAddContent(parent->last,
 xmlBufferContent(cur->content));
 #endif
             xmlFreeNode(cur);
             return(parent->last);
         }
     }

 and a little later....

     /*
      * Coalescing
      */
     if ((parent->type == XML_TEXT_NODE) &&
         (parent->content != NULL)) {
 #ifndef XML_USE_BUFFER_CONTENT
         xmlNodeAddContent(parent, cur->content);
 #else
         xmlNodeAddContent(parent, xmlBufferContent(cur->content));
 #endif
         xmlFreeNode(cur);
         return(parent);
     }

 Note that in these cases, the 'cur' node is freed; however, the 'cur'
 node is still used (as 'ret') inside the xmlStaticCopyNode code which
 results in a memory error.   The 'quick look' fix seems to be to change
 the call to:

     if (parent != NULL)
        ret = xmlAddChild(parent, ret);

If this fix is used, then there also needs to be a check for 'p != q' in
xmlStaticCopyNodeList or there is an infinite loop in
UPDATE_LAST_CHILD_AND_PARENT.  I tried the following:


static xmlNodePtr
xmlStaticCopyNodeList(xmlNodePtr node, xmlDocPtr doc, xmlNodePtr parent) {
    xmlNodePtr ret = NULL;
    xmlNodePtr p = NULL,q;

    while (node != NULL) {
 if (node->type == XML_DTD_NODE ) {
     if (doc == NULL) {
  node = node->next;
  continue;
     }
     if (doc->intSubset == NULL) {
  q = (xmlNodePtr) xmlCopyDtd( (xmlDtdPtr) node );
  q->doc = doc;
  q->parent = parent;
  doc->intSubset = (xmlDtdPtr) q;
     } else {
  q = (xmlNodePtr) doc->intSubset;
     }
 } else
     q = xmlStaticCopyNode(node, doc, parent, 1);
 if (ret == NULL) {
     q->prev = NULL;
     ret = p = q;
 } else  if (p != q) {  <-----------------------------Added this.
     p->next = q;
     q->prev = p;
     p = q;
 }
 node = node->next;
    }
    return(ret);
}
Comment 1 Greg Sjaardema 2002-01-10 14:45:46 UTC
Note that there is another similar call to xmlAddChild in
xmlNodeAddContentLen at line 3849 of tree.c
Comment 2 Daniel Veillard 2002-01-13 16:19:46 UTC
Right this seems a hard to trigger bug but still a bug :-)
I have tried to fix it in CVS, I cannot garantee it does completely
fix the problem though so I would appreciate if you could apply
the patch and check if this fixes your problem for good.

http://cvs.gnome.org/bonsai/cvsquery.cgi?module=gnome-xml&branch=HEAD&branchtype=match&dir=gnome-xml&file=&filetype=match&who=veillard&whotype=match&sortby=Date&hours=&date=explicit&mindate=01%2F13%2F02+11%3A14&maxdate=01%2F13%2F02+11%3A16&cvsroot=%2Fcvs%2Fgnome

  thanks !

Daniel
Comment 3 Daniel Veillard 2002-01-15 18:36:23 UTC
Should be closed in 2.4.13,

 thanks again !

Daniel