Re: [xml] Freeing xpath contexts vs xml docs...

[Daniel Veillard <veillard redhat com>]

On Fri, Mar 08, 2002 at 03:37:32AM -0500, Robert G. Brown wrote:
> Suppose you convert a document into an xmlDoc (via
> xmlParse[File,Buffer]) and then further convert it into an
> xmlXPathContext
> (via xmlXPathNewContext) so that you can use xpath to
> obtain a path to some particular node (as an xmlXPathObject) and extract
> its contents or attributes.

  That wording doesn't reflect the actual semantic of the operation.
xmlXPathNewContext create a new XPath context. That context is initialized
to work on that document. It does not modify the document in any way.
It doesn't either grab a hold on the document, multiple xmlXPathNewContext
could be created to run concurrent XPath queries. Also an xmlXPathContext
once create can be reused thing another document.
  Read the part about XPath in the XSLT internals
    http://xmlsoft.org/XSLT/internals.html#XPath

> 
> You have to free the object.  You have to free the doc.  However, even
> though there is an xmlXPathFreeContext function, I got truly bizarre
> behavior if I tried to free it; immediate crashes, crashes when I later
> tried to free the doc, crashes at random times when trying to execute
> simple xpath evals later on.  Freeing the doc first and then the context
> would immediately and consistently crash, though.  I discovered that if
> I didn't free the context but did free the document, things seemed to
> work (at least past the point where they crashed before:-).

  Freeing the context should have no side effect, really, the problem
must be somewhere else. But you must NOT free the document until all
the bit and pieces which may still use it as result of XPath queries
on it are in use.

> The xmlXPathNewContext command does not actually say that the pointer it
> returns must be freed by the caller while the other two do, so I suppose
> that this was my fault, but the contiguity of the two commands (and
> existence of the FreeContext command at all) does suggest that freeing a
> context is possible and/or necessary at least some of the time.

  Okay I added a sentence stating it must be freed by the caller.

> Is this empirical discovery correct?

  No, there must be something else.

> When (if ever) might one want to
> free a context?

  You can do this as soon as you don't have any XPath query running,
and since XPath evaluation API is synchronous this means "at any time".

> On the same line, in my application I cycle through a loop which obtains
> an xml source document via socket from each of a list of hosts, parses
> it into doc, transforms it to context, extracts specific tag contents
> via xpath, and then tries to free all dynamically allocated resources so
> that it can do the next host, and the next host and so forth "forever"
> without leaking.  That's why I've tried to be careful about calling
> ...Free...() functions.

  Did you had a look at the setup in place to do memeory checking in the
library:
   http://xmlsoft.org/xmlmem.html#Debugging

> Is there anything else I need to do to ensure that a long term cycle of
> 
> input->doc[->context]->object->free-object->object->free-object->free-doc,
> input->doc->...
> 
> won't leak or create other problems?

  I don't understand.
  The key points are: that nodes returned by XPath queries perterin to the
queried documents, they are not copies, that an xmlXPathContext is just the
set of data neeed to run an XPath evaultion, and that the unit of allocation
should be the document, you can free a document only when you know there is
no pointer left accessing any of its nodes or content.

> Should I periodically call e.g.
> xmlInitParser or xmlCleanupParser?

  No

> It is somewhat difficult to tell
> from the documentation, especially in the context of using xpath
> contexts (which may or may not get cleaned up).

  The documentation is clear IMHO
    http://xmlsoft.org/xmlmem.html#cleanup
Call xmlCleanupParser() only when you are done using the library.

> Sorry to be of trouble -- the application ALMOST works perfectly now
> that I'm using xpath from libxml2, but the memory management thing has
> eaten six hours straight and debuggers aren't very much help.

  which is precisely why I have written a specific doc and tool to
do those checkings:
   http://xmlsoft.org/xmlmem.html
  Is "Memory Management" mislabelled. I could probably add more informations.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/