13 May 19:45
Re: glibc hppa build failure - ulimit
Matthew Wilcox <matthew <at> wil.cx>
2005-05-13 17:45:35 GMT
2005-05-13 17:45:35 GMT
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? -- -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain(Continue reading)
RSS Feed