So, I've got a tricky to repeat segfault that occurs on an edge case, and I'm wondering if it's even an lxml bug, or a libxslt bug? What appears to be happening, is that if I run this stylesheet which has an undefined variable reference in an xpath expression, sometimes I can get a segfault. Not always, and it seems to be based on what other xml has been processed beforehand. If I start with a clean slate, it works fine and raises an exception as expected. If I run a bunch of other stuff first (yeah, I know how vague this is, and will work on a real test case), it reliably segfaults for me. A coworker noticed this problem, his symptoms were different, instead of segfaulting, the XSLT parser would unexpectedly exit (with no exception!) at the point where the invalid xpath was run, returning whatever result document had been generated up to that point. <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:gizmo="http://www.lt-systems.com/gizmo.xsd"> <xsl:output method="xml" indent="no"/> <xsl:template match="/"> <root> <first/> <!--<xsl:variable name="var" select="1"/>--> <xsl:value-of select="$var"/> <second/> </root> </xsl:template> </xsl:stylesheet> As I don't have debug symbols, the backtrace on the core dump is fairly useless. Does look like it's deep in libxslt where it breaks though. #0 0xb76f127d in ?? () from /usr/lib/python2.5/site-packages/lxml/etree.so (gdb) bt #0 0xb76f127d in ?? () from /usr/lib/python2.5/site-packages/lxml/etree.so #1 0xb7dcaff4 in ?? () from /lib/libc.so.6 #2 0xb7747dd3 in ?? () from /usr/lib/python2.5/site-packages/lxml/etree.so #3 0x083b7459 in ?? () #4 0xbff57388 in ?? () #5 0xb7ce3a6e in sprintf () from /lib/libc.so.6 #6 0xb76f1673 in ?? () from /usr/lib/python2.5/site-packages/lxml/etree.so #7 0x088cd9dc in ?? () #8 0xbff573c0 in ?? () #9 0xb7688430 in ?? () from /usr/lib/libxslt.so.1 #10 0x083b7450 in ?? () #11 0xb75f9af5 in ?? () from /usr/lib/libxml2.so.2 #12 0xb7dcc120 in ?? () from /lib/libc.so.6 #13 0x00000030 in ?? () #14 0x083b7450 in ?? () #15 0xb7688430 in ?? () from /usr/lib/libxslt.so.1 #16 0xb7dcc120 in ?? () from /lib/libc.so.6 #17 0x083f333c in ?? () #18 0xbff57438 in ?? () #19 0x00000016 in ?? () #20 0x00000000 in ?? () The lxml tests run fine for me: TESTED VERSION: 2.0.5 Python: (2, 5, 2, 'final', 0) lxml.etree: (2, 0, 5, 0) libxml used: (2, 6, 31) libxml compiled: (2, 6, 31) libxslt used: (1, 1, 24) libxslt compiled: (1, 1, 24) 899/899 (100.0%): Doctest: xpathxslt.txt ---------------------------------------------------------------------- Ran 899 tests in 20.205s OK PYTHONPATH=src python selftest.py 173 tests ok. PYTHONPATH=src python selftest2.py 94 tests ok. I'll run it through valgrind tomorrow when I have more time, and see if that provides anything interesting. I don't imagine there'll be much useful to be done until I can come up with a real test case, just hoping there's something obvious. -- John Krukoff <jkrukoff@ltgc.com> Land Title Guarantee Company