Re: [xslt] Segmentation fault with an infinite loop

[Mike Hommey <mh glandium org>]

Thanks to additional help from William Brack, I've been able to 
understand what is happening on my system, and on any Debian system 
running a linux kernel version < 2.6 (and probably < 2.5.xx but i don't 
know xx...).

I don't know for other linux distributions, but in the case of Debian, 
the libc6 package provides 2 flavours of the glibc : "normal" and "tls".
For some reason it has been decided to not support tls on 2.4 kernels, 
therefore, the running environment between 2.4 and 2.6, on the libc 
point of view, won't be the same.

What happens is that with 2.6, running a threads-enabled libxml2/libxslt 
program (such as xsltproc), will use /lib/tls/libpthread.so.0, while 
running it on 2.4 will use /lib/libpthread.so.0.
The difference between these two is that the latter has a fixed stack 
size for threads, and this size is set to 2MB (i don't know why it is 
set in only one, though, that might be related to the tls implementation).

So, a debian system running kernel 2.6 won't get the segfault I got, 
while a debian system running kernel 2.4 and a threads-enabled 
libxml2/libxslt program (such as xsltproc), will get this segfault.

Recompiling libxml2, libxslt, *and the program* (see below) without 
threads support also fixes the problem, since in that case libpthread 
won't be used therefore not limiting stack size.

Now, why do we need to recompile everything ? Because even though 
libxml2 is the only one to have the --without-threads flag to 
./configure, if libxslt was compiled against a libxml2 without this 
option, it will be compiled against libpthread, and the same applies to 
xsltproc and any frontend to libxslt that would be using threads. So if 
you only recompile libxml2, only half of the chain will have thread 
support disabled.
By the way, wouldn't it be safer to have a runtime test for enabling or 
not threads ? Because using a thread enabled libxslt with a thread 
disabled libxml2 might be risky, isn't it ?

Anyways, now, what I'll do is documenting the issue in a README.Debian 
file in the libxslt1.1 package. I guess there are no such possible 
issues when only using libxml2 (no potential infinite loop or huge stack 
consumption, right ?).
Another possibility would be to decrease the maxdepth in the package, 
but the value might be architecture dependant, and maybe the stack usage 
is stylesheet/xml file dependant ?

William, thanks again for your help with this issue.

Mike