[OT] RE: [xslt] Segmentation fault with an infinite loop

["Jesse Pelton" <jsp PKC com>]

Here I thought it was "Sod's Law."
http://www.heretical.com/miscella/sodslaws.html seems to think so too.

Bill, I've watched your responses to the list for quite a while, and I
am continually impressed by your careful work and generosity with your
time.  Bless you!

-----Original Message-----
From: xslt-bounces gnome org [mailto:xslt-bounces gnome org] On Behalf
Of William M. Brack
Sent: Wednesday, July 07, 2004 11:46 AM
To: The Gnome XSLT library mailing-list
Subject: Re: [xslt] Segmentation fault with an infinite loop

Mike Hommey said:
> Here we go, copy/paste from gdb output of a full backtrace:
> (Note that I cut after #49, and it goes up to #21807...)
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 16779)] 0x4013d56d in 
> xmlXPathObjectCopy__internal_alias (val=0x804fc18)
>      at xpath.c:3291
> 3291    xmlXPathObjectCopy(xmlXPathObjectPtr val) {
> #0  0x4013d56d in xmlXPathObjectCopy__internal_alias (val=0x804fc18)
>      at xpath.c:3291
>          ret = 0x0
> #1  0x4014b261 in xmlXPathCompOpEval (ctxt=0x80b0180, op=0x804fa70)
>      at xpath.c:10289
<snip>
>
>
> Mike


Hi Mike,

  I spent quite a bit of time chasing after this, trying on different
systems, different software versions, etc. etc., but was initially
unable to reproduce the problem (similarly to the others who have
responded on the list).  I then went through the gdb dump you posted and
unfortunately (through something known as Saud's
law) worked backwards.  There was nothing amiss until I got to frame 0 -
the crash was not on an executable line of code, but rather on the
arrival to a called routine, before any work had begun.  This tends to
indicate that the actual cause of the crash was not a problem within the
library, but rather was due to the fact that your process did not have
sufficient stack space allocated to it.

  Despite a couple of queries, I don't believe you have ever told us
which OS and/or distribution you are using.  On two of my systems, by
default (using a generic Linux 2.4 or 2.6 kernel) a process has 8192KB
of stack space allocated to it (as can be displayed using the "ulimit
-a" command).  On my Fedora Core 1 system, the default stack space is
10240KB.  With either of those settings, everything works properly.  If
I manually change that, downwards, to a bit less that 2000KB, I get
exactly the symptoms you have described, including a standalone crash,
runs ok under valgrind, and a gdb backtrace of just over 20K frames.

  Could you please let the list know more details about your
configuration, and also a copy of your "ulimit -a" output?  If, in fact,
your stack space is less than 8192KB, I would suggest you change it up
to that figure and see if the problem is solved.

HTH,

Bill


_______________________________________________
xslt mailing list, project page http://xmlsoft.org/XSLT/ xslt gnome org
http://mail.gnome.org/mailman/listinfo/xslt