Re: glibc hppa build failure - ulimit
On Fri, May 13, 2005 at 06:45:35PM +0100, Matthew Wilcox wrote:
> On Fri, May 13, 2005 at 01:21:48PM -0400, Daniel Jacobowitz wrote:
> > On Fri, May 13, 2005 at 05:38:33PM +0100, Matthew Wilcox wrote:
> > > On Fri, May 13, 2005 at 12:17:18PM -0400, Daniel Jacobowitz wrote:
> > > > 27319 mmap(NULL, 1073741824, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...>
> > > > 27319 <... mmap resumed> ) = -1 ENOMEM (Cannot allocate memory)
> > > >
> > > > Right now I don't think we could even rebuild glibc -21. The hppa
> > > > machines are configured with ulimit -s set to 1GB. This makes
> > > > LinuxThreads use 1GB thread stacks. Which is, um, pretty bad.
> > >
> > > PA machines grow the stack upwards, starting at 0xffffffff - hard
> > > stack limit. glibc never used to pay attention to the stack limit,
> > > choosing always to use 4MB stacks (iirc). When did glibc change that?
> >
> > Probably when Carlos added a patch to glibc which defined
> > FLOATING_STACKS. Glibc throttles the size to 8MB if the rlimit is
> > infinity, but trusts the rlimit if it is explicitly larger than 8MB.
>
> Ugh. Can we change the logic there to throttle to 8MB if the rlimit is
> larger than 1GB and we're building a 32-bit libc?
In the future? Probably, ask Carlos. But for sarge, I'd much rather
not make additional changes.
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: