Daniel, 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 [email protected] 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:[email protected]] Sent: 2012 April 16 Monday 5:35 AM To: Bruce Sinclair Cc: [email protected] 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 -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [email protected] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ This message has been scanned by MailController - portal1.mailcontroller.co.uk _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
