On Thu, Jun 12, 2025 at 2:27 PM Chet Ramey <chet.ra...@case.edu> wrote:
> On 6/12/25 9:17 AM, Joel Ebel wrote: > > > > > > On Thu, Jun 12, 2025 at 9:09 AM Joel Ebel <jbe...@google.com > > <mailto:jbe...@google.com>> wrote: > > > > > > > > On Wed, Jun 11, 2025 at 4:03 PM Chet Ramey <chet.ra...@case.edu > > <mailto:chet.ra...@case.edu>> wrote: > > > > On 6/7/25 4:42 PM, Joel Ebel via Bug reports for the GNU Bourne > > Again SHell > > wrote: > > > > > I appreciate the effort to make the test run more efficiently > > and faster, > > > and that's probably a good idea, but I think there still needs > > to be a way > > > out. I didn't express just how huge our ARG_MAX is. It's 2^62 > or 4.6 > > > exabytes. I don't think there's any way to reasonably expect > > that this test > > > will complete with that environment, so I still need a way of > > skipping the > > > test. > > > > So `getconf ARG_MAX' returns 4611686018427387904? I can do > something > > with that. > > > > That's correct > > > > > > It's possible that getconf isn't even available in our testing > environment, > > If it weren't you would have seen an error (probably multiple errors) while > running the test suite. > > > but I'm not sure why the script is giving me such a large number there. > > I just computed 2**62; I can work around large numbers greater than some > ARG_MAX max or numbers that overflow. > > After some digging, we found that in our environment there's no upper bound on RLIMIT_STACK, so it's set to the maximum allowed value of RLIM64_INFINITY or 2^64-1 Then make sets the stack limit to the maximum value, again RLIM64_INFINITY. glibc calculates ARG_MAX by dividing the current value of RLIMIT_STACK by 4, which gives us the 2^62-1 we're seeing.
