Photo by alen.
This is what I was seeing on my Fedora Core (FC5) system:
[wiseman@dhcppc4 ~]$ sbcl mmap: wanted 41938944 bytes at 0x1000000, actually mapped at 0xb55f1000 ensure_space: failed to validate 41938944 bytes at 0x01000000 (hint: Try "ulimit -a"; maybe you should increase memory limits.)
Standard advice is the following:
- Make sure you really do have enough memory and your ulimits are reasonable.
- Use setarch:
setarch i386 sbcl
- Disable Exec Shield:
echo 0 > /proc/sys/kernel/exec-shield
- Disable memory map randomization:
echo 0 > /proc/sys/kernel/randomize_va_space
None of those was sufficient for me. James Y. Knight supplied the crucial missing step:
- Disable prelinking. First un-prelink the particular library causing me problems:
prelink -u /lib/libpthread-2.4.so
Then tell the prelinking cron job to un-prelink everything the next time it runs by setting PRELINK=no in /etc/sysconfig/prelink.
Sounds familiar. A similar bug on Debian is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360561
Sadly, Lisp tends to be one of the first things to die when system internals change.
Posted by: ken on November 29, 2006 02:04 PMThat debian bug is in fact a packaging error for the kernel. 2.4.18-3-686 and friends seem to work again.
OTOH do not ask me about sparc without a good beer in my hand.
Posted by: Peter Van Eynde on November 30, 2006 12:51 PMAnd you think that going through these crazy contorsions is an acceptable requirement for running SBCL...? Does ease of use, or my desire to keep my box secure, even register on the SBCL developers' radar?
To any sane person, the crucial "missing step" would be fixing SBCL. Or dumping it for something that works.
Alas, I see nothing much has changed in the SBCL ecosystem.
Posted by: Dan on December 1, 2006 07:15 PMIt makes me worry a bit.
If it makes you worry, why not try to fix it? Or by all means, dump it for something that works for you; that's your choice. (I seem to have to say this quite often on this weblog: the SBCL developers do not exist for your convenience).
Fine, Xophe, but then SBCL should not be advocated as "the" Common Lisp solution. It's badly broken in certain environments, and it can be a time trap for unsuspecting users.
And, please, shed that "screw the users" attitude already. It's disgraceful. Even if you are working on an "Open Sores" project, as Hani (the BileBlog guy) likes to say, it still looks bad.
Posted by: on December 7, 2006 06:25 AMI hope I've never advocated SBCL as "the" Common Lisp solution, and I find it unlikely that I ever will; I even said in these comments that not using SBCL was fine by me. Fortunately, Common Lisp has an (admittedly antiquated) standard, so the cost to unsuspecting users from using the wrong implementation to start off with is likely to be relatively low if it turns out they have to migrate away from it.
As for the "screw the users", it's not that at all! It is about empowering the users to do something about their own problems. If they choose not to do so, but instead to post anonymous whines on the InterWeb, then they will get the service they deserve.
Ironically, I think Dan upthread had it right, although I suspect he intended in his comment to imply that all SBCL developers were insane: fixing SBCL, or dumping it for something that works, is the right answer. Where we differ is whose responsibility it is to ensure that that happens; Dan seems to imply, and John seems to think, that a fix for this should magically appear from the minds and efforts of a mythical class of being called "SBCL developers". I think that the fix, or at the very least the impetus towards finding a fix, should come in the first instance from those who are affected by the problem.