On Mon, Nov 14, 2022 at 01:04:45PM +0000, Koakuma wrote: > On 7.2-current/sparc64, `fork-exit` regression test fails with these errors: > > ==== run-fork1-heap ==== > # allocate 400 MB of heap memory > ulimit -p 500 -n 1000; ./fork-exit -h 100000 > fork-exit: child 73240 signal 11 > *** Error 1 in sys/kern/fork-exit (Makefile:60 'run-fork1-heap') > FAILED > [...] > Here's some observation that I made when experimenting with those tests: > > 1. From the description and the command, some of the *-stack tests seems > to want to allocate 400 MiB of stack space, but on my system I can only > bump > the stack limit to 32 MiB, even with ulimit/login.conf tweaks. Reducing > the -s option in the tests to a lower number seem to make it pass, > at least. > 2. When the test does hit the stack limit, it seems to spend a lot of time > doing something upon exit. I suppose this is why I'm observing timeouts? > 3. With -h, the mmap at line 84 > (https://github.com/openbsd/src/blob/master/regress/sys/kern/fork-exit/fork-exit.c#L84) > seems to be returning a valid address, but then segfaults on > the following p[1] statement at line 87. > 4. With -t option set, it seems that created threads will race on heap and/or > stack counters? I'm unfamiliar with pthread so I'm probably wrong here. > 5. With -t option set, it seems to set the per-thread stack limit to something > very low that stack tests would often fail regardless of how small > the stack allocation is set. > > Unfortunately, I have no idea on how to properly handle the first four issues, > but issue (5) can be worked around by increasing the per-thread stack area, > like so:
I think that these tests are expected to be run as root (in order to not have unlimited stacksize-max). But I don't have sparc64 to check if it is fine. -- Sebastien Marie
