Re: [xml] xmlAddChild question


Thanks, but I think you omitted a special case.  My memory leak was caused when I used xmlChildNode to add an 
empty text node.  The xmlChildNode function succeeded (non-null returned) but the text node was neither freed 
nor linked into the tree.  This lost 109 bytes per occurrence and was inside a large document with many empty 
text nodes being constructed multiple times (the document was freed before constructing another).  
Eventually, the leak overwhelmed the memory manager.  I fixed the leak by testing for an empty text node and 
not attempting to add it as a child.  I was just curious if this was a bug or my lack of understanding of 
xmlChildNode.  You explanation helps, but did not address the addition of an empty text node.

Bruce Sinclair
Software Systems Developer - Senior Principal

Micro Focus

bruce sinclair microfocus com
8310 N. Capital of Texas Hwy.
Building Two, Suite 100
Austin, Texas  78731-1002
Direct: +1 512 340 4717

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com] 
Sent: 2012 April 16 Monday 5:35 AM
To: Bruce Sinclair
Cc: xml gnome org
Subject: Re: [xml] xmlAddChild question

On Tue, Apr 10, 2012 at 05:50:07PM -0500, Bruce Sinclair wrote:
The description of xmlAddChild says:


"Add a new node to @parent, at the end of the child (or property) list 
merging adjacent TEXT nodes (in which case @cur is freed)."


and the description of xmlAddChildList says:


"Add a list of node at the end of the child list of the parent merging 
adjacent TEXT nodes (@cur may be freed)"


Assuming that @cur is freed in the case of "merging adjacent text nodes"
(as the sentence seems to read and bolstered by the "may" in the 
second description above), how is one to know whether adjacent TEXT 
nodes were merged in order to know whether @cur is freed?


We had a case of a memory leak because we generally assumed @cur was 
freed, but when we added an empty value text node, it was not.  We 
don't generally have "adjacent TEXT nodes", so it seems that "merging 
adjacent TEXT nodes" is not a qualification of whether @cur is freed, 
which would mean no information is necessary on the status of node 
merges.  Our experience is that the @cur is freed if the function 
succeeds, except in the case of adding an empty text node (even though 
the add child function succeeds in this case).  Can you clarify when 
@cur is freed or not freed?

  In general cur is *not* freed, it is linked to the parent at the end of the children list. Only when the 
last item of that list is a text node and cur is a text node, then libxml2 will merge the two and as a result 
cur will be freed.
  In general cur will be freed when the parent is freed (usually when the containing document is freed).
  The case that you must account for is when the function fails (in which case it will return NULL) and in 
that case cur is not linked to the parent and won't be freed when the document is freed, and there you have a 
leak. You must watch xmlAddChild() return value !
  The warning about mergind of text nodes is that people were trying to use @cur after the call, which worked 
most of the time, until text merging happen in which case they were referencing freed memory and crash !


Daniel Veillard      | libxml Gnome XML XSLT toolkit
daniel veillard com  | Rpmfind RPM search engine | virtualization 

This message has been scanned by MailController -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]