[lxml-dev] Possible bug, libxml segfault?

Hi folks :) I sent this message to the xml@gnome list, but that place is seems very quiet lately. I'm hoping someone here might have some insight. Indeed this might be a bug in lxml, we're not sure. Background: We use libxml and libxslt in one of our applications (specifically, in Python via lxml). Recently we've seen our application dying at strange times for no apparent reason. We managed to get a core file out of one crash, and the results of some of our debugging are here: http://xml.pastebin.com/m70c259d6 (I'd be happy to poke more in a particular direction on there, I'm a bit new to gdb :) To me, it seems the parser is complaining while trying to parse the namespaces in the <stylesheet> node in transforms/_base.xslt The node for that opens like this: <xsl:stylesheet version="1.0" xmlns="http://www.w3.org/1999/xhtml"; xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; xmlns:tfxslt="http://tfnet.co.uk/ns/tfxslt"; xmlns:fb="http://www.facebook.com/2008/fbml"; extension-element-prefixes="tfxslt str exsl" exclude-result-prefixes="str exsl tfxslt fb" xmlns:error="http://www.woome.com/error/";> I dug a little deeper and found a bunch of the "address out of bounds" errors and thought I should ask here as I'm drawing a blank on where to go next. The problem happens intermittently, but usually several times a day. I could probably reproduce it. I also see the 'exclude-result-prefixes' mentioned in the backtrace, could that be involved here? Any suggestions you have would be much appreciated!

Hi, Avleen Vig wrote:
The information you give is pretty informative. It just lacks a hint which versions of lxml, libxml2 and libxslt you are using. Is this reproducible with the latest release versions of all three?
The triggering problem is that you try to exclude the namespace prefixes "str" and "exsl" which are not defined in your stylesheet. This seems to induce a problem in lxml's error reporting mechanism in your specific setup. Is your application threaded? I do remember a couple of problems with threaded error reporting in the past, although all of those were solved back then. Stefan

On Sat, May 30, 2009 at 12:25 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
lxml 1.3.6 libxslt 1.1.22 libxml 2.6.31
We're running it with the Spawning python module (which uses threading), otherwise it's just a regular Django app. I haven't had a change to try this with the latest lxml. I'll try to soon. Something changed and made the problem happen much less frequently, so not sure what's going on there :)

Hi, Avleen Vig wrote:
The information you give is pretty informative. It just lacks a hint which versions of lxml, libxml2 and libxslt you are using. Is this reproducible with the latest release versions of all three?
The triggering problem is that you try to exclude the namespace prefixes "str" and "exsl" which are not defined in your stylesheet. This seems to induce a problem in lxml's error reporting mechanism in your specific setup. Is your application threaded? I do remember a couple of problems with threaded error reporting in the past, although all of those were solved back then. Stefan

On Sat, May 30, 2009 at 12:25 PM, Stefan Behnel <stefan_ml@behnel.de> wrote:
lxml 1.3.6 libxslt 1.1.22 libxml 2.6.31
We're running it with the Spawning python module (which uses threading), otherwise it's just a regular Django app. I haven't had a change to try this with the latest lxml. I'll try to soon. Something changed and made the problem happen much less frequently, so not sure what's going on there :)
participants (2)
-
Avleen Vig
-
Stefan Behnel