[lxml-dev] Segfault on XSLT/XPath undefined variable error.

[John Krukoff]

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 at ltgc.com>
Land Title Guarantee Company