[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