-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With both these releases, only root can run sbcl. I think I've traced
the problem to the (massive) overcommit on initialisation using mmap().
~ Ordinary users (in the 'default' /etc/login.conf class) have hard VM
limits (i.e. {set,get}rlimit(2)) below this, whereas root (in the
'daemon' class) doesn't. I've looked for a directive to raise the VM
limit, but couldn't find it. Raising the in-core limit (predictably)
didn't work.
TIA
- --
Darren Bane
PGP key available from keyservers or my .plan
Key ID: 2DA0C6EF. Call me for the fingerprint.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAjzAH28ACgkQ0a8MNS2gxu/dnACeIc67i01+sJ9i+/kXrKwinGTR
E0YAn0l9zje2zhPsH5ArhZfm2Q057Q/t
=pTYf
-----END PGP SIGNATURE-----
Darren Bane <······@blackhole.ir.intel.com> writes:
> With both these releases, only root can run sbcl. I think I've traced
> the problem to the (massive) overcommit on initialisation using mmap().
> ~ Ordinary users (in the 'default' /etc/login.conf class) have hard VM
> limits (i.e. {set,get}rlimit(2)) below this, whereas root (in the
> 'daemon' class) doesn't. I've looked for a directive to raise the VM
> limit, but couldn't find it. Raising the in-core limit (predictably)
> didn't work.
Hmmm, I think CMU CL and SBCL do similarly things with mmap, and at
least on a standard OpenBSD 2.9 install, normal users seem to be able
to use CMU CL without problems, even with the default ulimits:
bash-2.05$ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) 65536
file size (blocks) unlimited
max locked memory (kbytes) 18226
max memory size (kbytes) 54680
open files 64
pipe size (512 bytes) 1
stack size (kbytes) 4096
cpu time (seconds) unlimited
max user processes 64
virtual memory (kbytes) 69632
bash-2.05$ ulimit -aH
core file size (blocks) unlimited
data seg size (kbytes) 262144
file size (blocks) unlimited
max locked memory (kbytes) 54680
max memory size (kbytes) 54680
open files 1024
pipe size (512 bytes) 1
stack size (kbytes) 32768
cpu time (seconds) unlimited
max user processes 128
virtual memory (kbytes) 294912
bash-2.05$ lisp
CMU Common Lisp 18c+ 2001-12-04, running on openbsd
Send questions and bug reports to your local CMU CL maintainer,
or to ··········@cons.org. and ·········@cons.org. respectively.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
*
So maybe this is a change in OpenBSD handling of mmap in release 3.0
(though I haven't heard of problems with CMU CL and 3.0)?
If OpenBSD 3.0 is strict in its checking of mmap against ulimits, then
only root can really help you there.
[ There are patches for CMU CL that do lazy mmapping of memory zones,
but those can cause crashes if/when OS allocated memory happens that
claims address space in the middle of CMU CL's zone... ]
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pierre R. Mai wrote:
[snipped]
| bash-2.05$ ulimit -aH
Thanks, this helped me figure it out. For the benefit of future
googlers, here's what's going on:
OpenBSD 3.0 does seem to enforce resource limits more strictly. In
particular, it won't let mmap() exceed the _soft_ limit. Pierre's
response hints that 2.9 let you away with this, enforcing the hard limit
instead.
Of course, it didn't help that I was trying to bump up the wrong limit
:-( The sbcl mmap() is actually in the _data_ segment, so the fix is to
just put
~ ulimit -S -d 524288
in your .profile (or csh equivalent).
[snipped]
- --
Darren Bane
PGP key available from keyservers or my .plan
Key ID: 2DA0C6EF. Call me for the fingerprint.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAjzEWlMACgkQ0a8MNS2gxu+0YgCfUKuteaNez6nfN80wKGLsfWVI
684AoKlah+ZeznR0Gb+nl0kOBgz8eoA+
=gUOm
-----END PGP SIGNATURE-----