[lxml-dev] Dealing with segfaults in lxml?

Steve Lianoglou lists.steve at arachnedesign.net
Thu Oct 4 00:50:50 CEST 2007


> I'm getting crashes - by which I mean the python process is
> segfaulting and, with some tweaking of GNU/Linux, leaving me a core
> file - while using lxml to parse data.
>
> Versions:
>
> OS: RHEL 5
> Python: 2.5.1 (custom built).
> lxml: 1.3.3
> libxml: 2.6.26 (both compiled and built)
> libxslt: 1.1.17

As an aside (addendum?, whatever ..) I recently got nailed w/  
segfaults and bus errors that seemed to not be 100% reproducible on  
OS X.

I built lxml against:

libxml 2.6.30
libxslt 1.1.22
python2.5.1(and python2.4.4)
lxml 1.3.4
(all using MacPorts)

My code was basically generating large(-ish -- though really not much  
bigger than 4 megs or so) documents like so (inspired from  
ElementTree examples):

import lxml.etree as ET
root = ET.Element('graph', **root_attribs)
ET.SubElement(root, 'node', id='something', label=name)
ET.SubElement(node, 'att', name='pvalue', type='real', value=pval)
...

The nesting level wouldn't ever really go more than 3 or 4 children  
deep.

Anyway, I know there was talk about lxml crashing w/ the default OS X  
xml libs, but here's the case when I'm using the newer ones.

I don't know if this is the same issue as Mike's having, but since  
this just happened to me and I haven't been able to smoke it out, I'm  
bringing it up here (in the meantime I've switched to elementtree and  
the same code works fine (if not slower)).

I will try to create a minimal test case after one of my deadlines  
pass to help smoke this out better(also, I don't know if the minimal  
test case will help, is it possible that it's a function of the size  
of the xml doc that I'm trying to build?)

Thanks,
-steve


More information about the lxml-dev mailing list