November 29, 2006
SBCL, mmap and New Unix Tricks
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:
None of those was sufficient for me. James Y. Knight supplied the crucial missing step:
Posted by jjwiseman at November 29, 2006 12:56 PM
That 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.
And 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.
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.
I 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.