[cl-debian] Bug#402508: Same bug here, and a (crazy) work around

[Alexei Sheplyakov]

Hello!

I've tried to install sbcl on my x86_64 box, and got

# aptitude install sbcl
Reading package lists... Done
Building dependency tree... Done
Reading extended state information      
Initializing package states... Done
Writing extended state information... Done
Building tag database... Done             
The following NEW packages will be installed:
  sbcl 
0 packages upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B/8816kB of archives. After unpacking 42.1MB will be used.
Writing extended state information... Done
Selecting previously deselected package sbcl.
(Reading database ... 109938 files and directories currently installed.)
Unpacking sbcl (from .../sbcl/sbcl_0.9.16.0-1_amd64.deb) ...
Setting up sbcl (0.9.16.0-1) ...
/usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc.
mmap: Cannot allocate memory
ensure_space: failed to validate 8589869056 bytes at 0x1000000000
(hint: Try "ulimit -a"; maybe you should increase memory limits.)
mv: cannot stat `sbcl-new.core': No such file or directory
FAILED

\begin{sarcasm}
hint: maybe sbcl should not allocate insane amounts of memory?
\end{sarcasm}

Anyway, I've checked it, all limits are infinite. However, the box has "only"
2Gb of RAM and 1Gb of swap, so the kernel won't allow to more than 3Gb of
memory, because the memory overcommiting is switched off:

$ cat /proc/sys/vm/overcommit_memory
2

I use such configuration since it allows programs to handle out of
memory conditions gracefully (at least, the kernel won't kill unrelated
processes), prevents well known "swap of death", stops fork bombs, etc.

To debug the problem, I've tried to revert to the default default
setting, so called "heuristic overcommiting".

# echo 0 > /proc/sys/vm/overcommit_memory

Still the same error. So, I've complitely switched of the sanity checks:

# echo 1 > /proc/sys/vm/overcommit_memory

("always overcommit"),

and reinstalled sbcl. This time it worked fine. However, such work around
is clearly inacceptable.

> "ulimit -H -a", "ulimit -S -a",

# ulimit -H -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 39
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 99
stack size              (kbytes, -s) unlimited
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

# ulimit -S -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 39
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 99
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited


> What does "cat /proc/self/maps",

# cat /proc/self/maps
00400000-00405000 r-xp 00000000 fe:13 543627                             /bin/cat
00504000-00505000 rw-p 00004000 fe:13 543627                             /bin/cat
00505000-00529000 rw-p 00505000 00:00 0                                  [heap]
2ed5f9301000-2ed5f9318000 r-xp 00000000 fe:13 655626                     /lib/ld-2.3.6.so
2ed5f9417000-2ed5f9419000 rw-p 00016000 fe:13 655626                     /lib/ld-2.3.6.so
2ed5f9419000-2ed5f941b000 rw-p 2ed5f9419000 00:00 0 
2ed5f942e000-2ed5f954f000 r-xp 00000000 fe:13 655631                     /lib/libc-2.3.6.so
2ed5f954f000-2ed5f964e000 ---p 00121000 fe:13 655631                     /lib/libc-2.3.6.so
2ed5f964e000-2ed5f9663000 r--p 00120000 fe:13 655631                     /lib/libc-2.3.6.so
2ed5f9663000-2ed5f9666000 rw-p 00135000 fe:13 655631                     /lib/libc-2.3.6.so
2ed5f9666000-2ed5f966b000 rw-p 2ed5f9666000 00:00 0 
2ed5f966b000-2ed5f986b000 r--p 00000000 fe:14 12618922                   /usr/lib/locale/locale-archive
71f56c42f000-71f56c445000 rw-p 71f56c42f000 00:00 0                      [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]

> "cat /proc/sys/kernel/exec-shield",

# cat /proc/sys/kernel/exec-shield
cat: /proc/sys/kernel/exec-shield: No such file or directory

However, I use grsecurity (http://www.grsecurity.net) patched kernel,
and I'm aware of possible issues with self-modifying executables/libraries.
I've tried disabling grsecurity (actually, PAX) restrictions and address
space layout randomization for sbcl binary, still the same error (unless
I switch on "always overcommit" mode).

> "cat /proc/sys/kernel/randomize_va_space" return?

1

AFAIK this is the default since 2.6.12 or so.

> Are you running prelink?

I do have prelink package installed (for execstack utility), however,
the cron job doing the actual prelinking is disabled.

Best regards,
	Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <https://mailman.common-lisp.net/pipermail/cl-debian/attachments/20071230/ea4b5079/attachment.sig>