[cl-debian] Re: [Sbcl-devel] sbcl with sb-threads not compatible with 2.4 kernel

[Peter Van Eynde]

Peter Van Eynde wrote:
>> Tell us how to reproduce it and what is the observed behaviour.

I got a better example:

3/pvaneynd at sharrow:~/fakeroot/darcs-upstream :( $ uname -a
Linux sharrow 2.6.12.3-mine2 #1 Fri Aug 5 18:19:08 CEST 2005 i686 GNU/Linux
3/pvaneynd at sharrow:~/fakeroot/darcs-upstream :) $ sbcl
This is SBCL 0.9.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (quit)
3/pvaneynd at sharrow:~/fakeroot/darcs-upstream :) $ LD_ASSUME_KERNEL=2.4.1
sbcl
This is SBCL 0.9.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
internal error #29
     SC: 14, Offset: 4   lispobj 0x50ba64f
fatal error encountered in SBCL pid 11009(tid 0):
internal error too early in init, can't recover
The system is too badly corrupted or confused to continue at the Lisp
level. If the system had been compiled with the SB-LDB feature, we'd drop
into the LDB low-level debugger now. But there's no LDB in this build, so
we can't really do anything but just exit, sorry.
3/pvaneynd at sharrow:~/fakeroot/darcs-upstream :( $ LD_ASSUME_KERNEL=2.4.1
sbcl
This is SBCL 0.9.3, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
Segmentation fault


Please note that the error changes. I got the idea from a debian bugreport:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301511&archive=yes

I quote: "Recent glibc switches to use NPTL instead of
LinuxThreads when 2.6 kernel is used. If you set environment variable
LD_ASSUME_KERNEL=2.4.1 and rerun his programs on 2.6 kernel, the
problem is just disappeared (because LinuxThreads is used).  Note that
NPTL uses futex for mutex protection, instead LinuxThreads uses
signal."

I traced the problem on a 2.4 kernel until the first nl_langinfo that 
blows up with a sigsegv, so it seems to possibly fit.

So getting threaded sbcl to work again on 2.4 looks a little too 
difficult to do in the short amount of time I have available.

Do people think it is better to have a sbcl that bombs out on 2.4 with 
"you should run 2.6" or should I drop the threading on x86?

Groetjes, Peter

-- 
signature -at- pvaneynd.mailworks.org
http://www.livejournal.com/users/pvaneynd/
"God, root, what is difference?" Pitr | "God is more forgiving." Dave
Aronson|
> sk17766