Re: [xml] suggestions to workaround a segmentation fault

On Thu, Nov 13, 2003 at 12:00:56PM +0100, Petr Pajas wrote:
Hallo Daniel, All,

First of all, I'd like to thank you for all the new stuff in 2.6.  For
example, the new xmlReadXY parser API functions and the new syntax for
parsing options. It simplifies and shortens the code and makes it much
more readable and more joy to write. Also, I found the new dictionary
code saves me over 20% of memory for my complex >20Mb XML files and
the parser seems even faster then before.

  okay, good :-)

Now, I'm still stuck with a problem related to xmlRemoveID. I really
need to find a workaround for this to continue my work (there is still
a lot to do on libxml2 Perl binding:-)). I tried to fix it with a
patch to libxml2, but the patch was rejected. Ok then, can somebody at

  It wasn't completely rejected... I have applied it locally to my tree
but won't commit until I find a way to fix the xmlReader based validation
problem it is associated with.

In my application, I don't have a control over what nodes are queried
and what nodes are removed. This is up to the user. The problem is,
that once a validating parser hashed an ID, xmlGetID returns the
pointer to the node even if the node was already unlinked from the
document and freed, and I can't failed to find a way to check that the
pointer is still valid.

IMO, the problem is, that current xmlRemoveID is semantically
equivallent to

xmlRemoveID(xmlDocPtr* doc, xmlDocPtr attr) {

  I don't disagree. This will get fixed once I find a solution which 
keep the parsing functionality. The parsing has a slightly higher priority
than tree API, especially since it's the status-quo. But I want both fixed.
I still have a valgrind --gdb-attach=yes python ./ session
around, but I didn't come yet to a solution to this problem, that's all.


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]