Mailman 3 March 2009 - lxml - The Python XML Toolkit

[lxml-dev] the subelements of my tree are moving alone
by TP 11 Mar '09

11 Mar '09

Hi everybody, I have derived custom classes from ET._ElementTree and ET.ElementBase to obtain a custom tree suited to my needs. It works perfectly, but it seems that the nodes under the root node (the subelements) move sometimes "alone". The tree structure is kept, but the address of the elements in memory is changing. As the structure is kept, it is not a problem for lxml use only: I can walk in the tree, doing what I need. But the problem is that I use this custom tree as the underlying data structure for a PyQt custom QTreeWidget. In this widget, I use the method "internalPointer()" of QModelIndex instances (as proposed in the chapter 16 of book "Rapid GUI Programming with Python and Qt" by Mark Summerfield (around p.500)). The problem is that if the nodes move, the "internalPointer()" of Qt are not up to date: I obtain segmentation faults. Is this normal that nodes of the tree move in memory *alone*? Is this due to the garbage collector? If yes, how to keep my pointers up to date? Thanks in advance -- python -c "print ''.join([chr(154 - ord(c)) for c in '*9(9&(18%.\ 9&1+,\'Z4(55l4('])" "When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong." (first law of AC Clarke)

2 2

[lxml-dev] Lxml Crash
by Alex Klizhentas 04 Mar '09

04 Mar '09

Hi all, sometimes i get exception killing apache process. It happens occasionally (acually it happened once on my production site), so I have no more logs up to the moment, I can only suspect that crash happens when I am trying to replace the node: def replace(self,child,new_child): root = self.getroottree().getroot() index = self.index(child) if root._should_notify(): old_child = deepcopy(child) self.insert(index,new_child) etree.ElementBase.remove(self,child) root._notify(NodeReplaced(old_child,new_child)) return self[index] else: self.insert(index,new_child) etree.ElementBase.remove(self,child) return self[index] crash log is below: *** glibc detected *** /usr/sbin/apache2: free(): invalid pointer: 0x08cd6eca *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb7e26a85] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7e2a4f0] /usr/lib/libxml2.so.2(xmlFreeNodeList+0x126)[0xa984d1e6] /usr/lib/libxml2.so.2(xmlFreeNode+0x76)[0xa984d656] /usr/lib/python2.5/site-packages/lxml-2.2alpha1-py2.5-linux-i686.egg/lxml/etree.so[0xa9992bf2] /usr/lib/python2.5/site-packages/lxml-2.2alpha1-py2.5-linux-i686.egg/lxml/etree.so[0xa99b529f] I will bring in more logs if crash repeats, but I will appreciate any ideas/thoughts/comments so I can quickly eliminate/workaround/prevent the issue from happening again. -- Regards, Alex

2 2

[lxml-dev] (re-raising) exceptions problem in lxml 2.2beta4
by jholg＠gmx.de 03 Mar '09

03 Mar '09

Hi, I just ran into a problem with some code that re-raises exceptions, where accessing sys.exc_info() returns (None, None, None) instead of the expected most recent exception information. This seems to happen if "some operation" is performed on the tree after the exception has been caught and before sys.exc_info() gets invoked. Looks like lxml clears the exception information somewhere on the way. Here's a minimal example where the invocation of iterchildren() triggers the behaviour: $ cat lxml_reraise.py import sys from lxml import etree print "using lxml version", etree.__version__ root = etree.Element('root') try: access = bool(sys.argv[1]) except IndexError: access = False try: raise RuntimeError('Too much foo for bar') except Exception, e: if access: print "children:", list(root.iterchildren()) print sys.exc_info() Run with lxml 2.1.5: $ python2.4 lxml_reraise.py using lxml version 2.1.5 (<class exceptions.RuntimeError at 0x132780>, <exceptions.RuntimeError instance at 0x25f0a8>, <traceback object at 0x25f080>) $ python2.4 lxml_reraise.py 1 using lxml version 2.1.5 children: [] (<class exceptions.RuntimeError at 0x132780>, <exceptions.RuntimeError instance at 0x1d5828>, <traceback object at 0x1d57d8>) Run with lxml 2.2beta4: $ ln -s ~/pydev/tmp/lxml-2.2beta4/build/lib.solaris-2.8-sun4u-2.4/lxml $ python2.4 lxml_reraise.py using lxml version 2.2.beta4 (<class exceptions.RuntimeError at 0x132780>, <exceptions.RuntimeError instance at 0x252260>, <traceback object at 0x252170>) $ python2.4 lxml_reraise.py 1 using lxml version 2.2.beta4 children: [] (None, None, None) Now, I seem to remember some discussion of changes wrt to exceptions for lxml 2.2. Might this be an (unwanted) side effect to these changes? Holger -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

2 1

[lxml-dev] Segmentation Fault loading graphml.xsd
by Chris Wj 02 Mar '09

02 Mar '09

Before posting a new bug I want to confirm this. I am reading in graphml.xsd as a Schema to validate against, which has other xsd files that it references located in same folder. Linux x86_64, Python 2.5, lxml 2.2beta4 lxml.etree: (2, 2, -96, 0) libxml used: (2, 6, 32) libxml compiled: (2, 6, 32) libxslt used: (1, 1, 24) libxslt compiled: (1, 1, 24) Code to reproduce error: In [1]: from lxml import etree In [2]: etree.XMLSchema(file="grap graphml+svg.xsd graphml-attributes.xsd graphml-parseinfo.xsd graphml-structure.xsd graphml.dtd graphml.xsd In [2]: s = etree.XMLSchema(file="graphml.xsd") Segmentation fault Schemas can be obtained here: http://graphml.graphdrawing.org/specification.html Loading the others seg faults too. -Chris

2 1