Subject: Re: egcs problem on m68k with -m68060
To: Simon Burge <email@example.com>
From: Frederick Bruckman <firstname.lastname@example.org>
Date: 04/18/1998 21:33:13
On Sat, 18 Apr 1998, Simon Burge wrote:
> On Sat, 18 Apr 1998 01:46:19 -0500 (CDT) Frederick Bruckman wrote:
> > On problem I have when compiling libc is that "make" often runs out of
> > memory, at some point after sucking up nearly half of my 36M of real
> > memory as viewed with `ps -orss,vsz,command'. I set up a spare disk as a
> > whopping 500M swap partition, just to see if that would make a difference,
> > but it doesn't. It will pick up where it left off, more or less, if I set
> > UPDATE=1, and then go to completion. My ulimit is unlimited. "make" seems
> > to come up against some hard limit imposed by the kernel. Isn't 36M
> > supposed to be enough to build the tree? Any ideas?
> You're probably running in to per-process limits. It sounds like
> you're using sh. The sh ulimit command talks about file sizes by
> default. Try a 'ulimit -H -a', then a 'ulimit -d <maxdatasize>'
> or 'ulimit -s <maxstacksize>' (or both). The man page for sh is
> helpful here.
That was it. I'm actually using bash, which has a ulimit with the same
syntax. make was evidently bumping into the soft limits for "data seg
size" and "max locked memory." Here's the default on my machine for
`ulimit -S -a.'
core file size (blocks) unlimited
data seg size (kbytes) 16384
file size (blocks) unlimited
max locked memory (kbytes) 10505
max memory size (kbytes) 31516
open files 64
pipe size (512 bytes) 1
stack size (kbytes) 512
cpu time (seconds) unlimited
max user processes 80
virtual memory (kbytes) 16896
and here's part of the output from the command
`ps amx -orss,vsz,pid,ppid,uid,tty,command' just as `make build' was
finishing with libc
RSS VSZ PID PPID UID TTY COMMAND
572 43540 78 1 0 ?? mount_mfs /dev/sd0b /tmp
16076 17120 20084 20083 0 ttyp0 make _THISDIR_ all
I only got that far by bumping both to 24000. The max "virtual memory" is
a bash extension. It can't be changed directly, but tracks "max data
size." All of the hard limits are much higher. From following along with
`ps', I figure I was coming up against the limit for "max locked memory,"
but would have ran into "max data seg size" as well. Thanks!