gnustep-dev
[Top][All Lists]
Advanced

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

Re: Unresolved Issues with libxml2


From: Doug Simons
Subject: Re: Unresolved Issues with libxml2
Date: Thu, 22 Mar 2012 18:24:14 -0600

Hi Fred,

I finally found some time to try the XML code with your recent changes. First, 
I appreciate all of the work you've done to finish up the parts of this code 
that we weren't able to complete in the initial implementation. Also, I can 
confirm that the change you made to implement prettyPrint seems to be working 
for me. The code you implemented for NSXMLNodeCompactEmptyElement is performing 
the right operation but in the opposite direction. So I reversed the logic and 
also added a test for the complementary NSXMLNodeExpandEmptyElement flag that 
(for some reason) Cocoa also defines. If neither flag is set, it defaults to 
the expanded form, which I believe is the default in Cocoa.

Some things seem broken, though. The first is that the change you made in 
-copyWithZone: (passing a value of 2 rather than 1 to the xmlCopyNode() 
function) stops it from copying the node's children. So I've changed that back 
to 1, which does a deep copy.

More serious is that I am getting a crash when dealloc'ing objects in some 
situations. I haven't fully tracked it down but I suspect it might be related 
to the code you added in the detach method that creates a new document and 
calls xmlDOMWrapAdoptNode(). I'm not sure what all of that does, but in 
debugging I noticed that I ended up with what looks to me like a malformed 
libxml node tree. I have a text node that has a parent and a document:

(gdb) p *node
$24 = {_private = 0x0, type = XML_TEXT_NODE, name = 0x4650d0 "text", 
  children = 0x0, last = 0x0, parent = 0x88e52f8, next = 0x0, prev = 0x0, 
  doc = 0x88e4ee0, ns = 0x0, content = 0x88e4f68 "7", properties = 0x0, 
  nsDef = 0x0, psvi = 0x0, line = 1, extra = 0}

Its parent is an element with a document, but no parent:

(gdb) p *node.parent
$27 = {_private = 0x88e4e44, type = XML_ELEMENT_NODE, name = 0x88e4f58 "num", 
  children = 0x88e5338, last = 0x88e5338, parent = 0x0, next = 0x0, 
  prev = 0x0, doc = 0x88e4ee0, ns = 0x0, content = 0x0, properties = 0x0, 
  nsDef = 0x0, psvi = 0x0, line = 0, extra = 0}

And the document that both of them belong to has no children:
(gdb) p *node.doc
$26 = {_private = 0x88e1c94, type = XML_DOCUMENT_NODE, name = 0x0, 
  children = 0x0, last = 0x0, parent = 0x0, next = 0x0, prev = 0x0, 
  doc = 0x88e4ee0, compression = -1, standalone = -1, intSubset = 0x0, 
  extSubset = 0x0, oldNs = 0x0, version = 0x88e4f48 "1.0", encoding = 0x0, 
  ids = 0x0, refs = 0x0, URL = 0x0, charset = 1, dict = 0x0, psvi = 0x0, 
  parseFlags = 0, properties = 32}

This seems like a bad state of affairs. If nothing else, it means that the 
rootDocument method will return an object that has no reference to its 
children. And I suspect that somehow this is leading up to the crash which 
occurs when the NSXMLDocument is dealloc'ed:

Program received signal SIGSEGV, Segmentation fault.
0x005db761 in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt 9
#0  0x005db761 in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x003a61f8 in xmlFreeNode () from /usr/lib/libxml2.so.2
#2  0x00944a11 in -[NSXMLNode dealloc] (self=0x88e1c94, _cmd=0xb3c9d0)
    at NSXMLNode.m:1192
#3  0x0093be62 in -[NSXMLDocument dealloc] (self=0x88e1c94, _cmd=0xb0e6e8)
    at NSXMLDocument.m:54
#4  0x008a2cc4 in -[NSObject release] (self=0x88e1c94, _cmd=0xadd8d0)
    at NSObject.m:2049
#5  0x007ea77f in -[NSAutoreleasePool emptyPool] (self=0x881a314, 
    _cmd=0xadd8c0) at NSAutoreleasePool.m:656
#6  0x007ea5a5 in -[NSAutoreleasePool dealloc] (self=0x881a314, _cmd=0xadd8b8)
    at NSAutoreleasePool.m:538
#7  0x007ea0c8 in -[NSAutoreleasePool release] (self=0x881a314, _cmd=0x2dfa30)
    at NSAutoreleasePool.m:531
#8  0x0020d699 in endFrame (self=0x835b18c) at STRuntime.m:462
(More stack frames follow...)

I may be wrong about what is causing this -- a quick attempt to remove the code 
I was suspicious of in the detach method didn't solve the problem. I'm afraid I 
can't take any more time with this right now, but I can tell you that this 
occurs after approximately this sequence of steps (it's hard for me to pin down 
the exact steps because this is all invoked by some higher-level code, but I 
think this is very close):

I create 2 NSXMLDocuments by calling [NSXMLDocument 
initWithXMLString:options:error:] with the strings "<num>6</num>" and 
"<num>7</num>"

In each of these Documents my code calls -rootElement to get the root element 
and then calls -detach on the element to remove it from its document. Then I 
believe -copyWithZone: is called on the root elements, and these copies are 
what are used by the rest of the code.

Then, in the first element, the code changes the contents from "6" to "7" by 
calling -setStringValue: on the text node.

Then the code compares the two detached element trees. All of that works fine 
until it releases the pool and crashes.

This same sequence of steps was working without crashing with the XML code as 
it existed a couple weeks ago. So I'm hoping maybe you have a clue about which 
changes might lead to this.

Thanks,

Doug




On Mar 14, 2012, at 4:27 PM, Fred Kiefer wrote:

> On 29.02.2012 23:28, Doug Simons wrote:
>> Since we've submitted the new implementation of the NSXML... classes
>> based on libxml2 and people are beginning to use them, I thought I
>> would mention some remaining unresolved issues in the hope that other
>> people might have more experience with the libxml2 libraries and have
>> some ideas about how to solve them. These are currently the top
>> issues on my list:
>> 
>> 1. Parsing an XML document generates text nodes in the tree for
>> whitespace between elements even when the XML_PARSE_NOBLANKS option
>> is given.  Cocoa doesn't do this.
>> 
>> 2. Find a way to control formatting of "empty" nodes. Cocoa has the
>> options NSXMLNodeExpandEmptyElement and NSXMLNodeCompactEmptyElement
>> to control whether an empty node foo is displayed as "<foo></foo>" or
>> as"<foo/>" . Currently our libxml2 implementation will only display
>> the latter.
>> 
>> 3. Find a way to control "pretty-print" formatting. Cocoa has an
>> option NSXMLNodePrettyPrint to control whether a string
>> representation of a tree will include indentation for enhanced
>> readability or not. Currently our libxml2 implementation always
>> includes indentation.
>> 
>> I have searched the libxml2 documentation for ways to control these
>> issues but haven't come up with anything that works (in particular I
>> tried the xmlKeepBlanksDefault() function for issue 1 without any
>> success).
> 
> I hope that I have solved the last two of your issues. Could you please give 
> it a try?
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]