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

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.
participants (1)
-
Alexei Sheplyakov