From: Peter V. E. <pva...@ma...> - 2005-08-11 21:21:17
|
Peter Van Eynde wrote: >> Tell us how to reproduce it and what is the observed behaviour. I got a better example: 3/pvaneynd@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@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@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@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 |