glibc hppa build failure - ulimit
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Daniel Jacobowitz
Quoted 8 lines · Matthew Wilcox
Quoted 6 lines · Daniel Jacobowitz
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.
Quoted 7 lines
Quoted 3 lines
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?
Signature · 11 lines
"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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]