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

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
(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

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

Is there anything else I need to do to ensure that a long term cycle of


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?


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
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:
  Is "Memory Management" mislabelled. I could probably add more informations.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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