Red Hat Bugzilla – Bug 124074
Loading a foreign function into SBCL crashes the kernel
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
SBCL (Steel Bank Common Lisp) provides a foreign function interface.
This worked as expected on Fedora Core 1. On Fedora Core 2,
attempting to use it crashes the kernel. (It stops responding to the
keyboard and mouse, but there is no "oops" or panic message.) As well
as being a nuisance in itself, this creates a local denial of service
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Download and install the SBCL RPM (version 0.8.10) from
2. Ensure that /usr/lib/libpq.so is installed. As far as I know,
Postgres has nothing to do with the problem, but the demo code
attempts to link against this library.
3. Create a file called test.lisp, containing the following line:
4. Save work and switch to a text console!
5. Enter the following command:
sbcl --load test.lisp
Actual Results: System stopped responding to the keyboard and mouse.
Expected Results: The Lisp toplevel prompt should have appeared.
If I had to take a guess, I would say that this problem is related to
overcommitment of memory. SBCL and CMUCL allocate large amounts of
address space which they do not actually use. This unusual behaviour
may have shown up a hidden kernel issue.
I have tried setting /proc/sys/vm/overcommit_memory to 1, but this
makes no difference.
A couple of other things I have found out:
1. Memory is not overcommitted -- I think that was probably a red
herring. The machine I was using has 4G of swap; while SBCL allocates
a lot of memory, it is not that much, so there is no overcommitment.
With a more typical amount of swap overcommitment might be expected to
2. I wanted to verify that it really was a kernel hang, and not SBCL
disabling keyboard-generated signals for whatever reason. Accordingly
I ran the command again, this time putting it in the background:
sbcl --load test.lisp &
As expected, I got the shell prompt back. I pressed return a few
times. At first, each press of the return key gave me a new shell
prompt. However after perhaps half a second, pressing return stopped
having any effect. At this point it was impossible to get a reaction
from the system -- I couldn't even switch virtual consoles --
suggesting that the kernel had indeed hung. The only things that
still worked were keys like Num Lock, which operated the keyboard LED
I have also been having trouble with SBCL. It locks up the kernel
completely whenever loading any larger ammount of code. Not sure if
this is related, but CLISP and CMUCL segfault under FC2 also. CLISP
segfaults when loading code, and CMUCL segfaults immediately when ran.
None of this happened under FC1. This is on an i686.
Hi, sorry to hear you're having trouble too. I just tried rebuilding
the SBCL RPM and again I got a lock-up. This, together with your
experience, makes me think that it isn't specific to the foreign
function interface. Probably anything that makes SBCL do a
significant amount of computation triggers the bug.
I also get the CMUCL segfault. Clisp wasn't reliable for me on FC1
either, and as far as I can tell it is about the same on FC2.
I have compiled the vanilla 2.6.6 kernel with selinux, but without the
4K stack. SBCL, CMUCL, and Clisp work now. Maybe its the 4K stack?
I don't know much about lisp compilers. I know SBCL shouldn't cause
linux to hang, though.
it's more likely the 4g/4g split patch.
Can any of you guys try the kernel from
http://people.redhat.com/arjanv/2.6 since we fixed at least one
crasher bug with that patch ?
I tried the kernel from the previous comment, and SBCL seems to work
correctly now. It doesn't crash when loading defsystem-3.4i. CMUCL
and Clisp, however, still segfault. Maybe those problems are unrelated.
I'm seeing the same as Dusty -- SBCL works, CMUCL doesn't. I don't
expect the CMUCL problem is the kernel's fault. If the 4g/4g patch
causes some addresses to move around, it's likely that CMUCL needs
Unfortunately Lisps tend to be very sensitive to the details of the
system where they are built. Because they are loaded in effect from a
core file, if anything at all moves the addresses will be wrong.
Rebuilding CMUCL is, apparently, a big undertaking. :-( I've never
tried to do it, but difficulties in this area were the reason for SBCL
forking off in the first place.
I'm very impressed with the support -- two days to provide a patched
kernel is amazing. Thank you. Do you know how long it's likely to be
before a fixed kernel is made available as an official Fedora update?
Feel free to close the bug; the issue is resolved as far as I am
*** Bug 124828 has been marked as a duplicate of this bug. ***