Bruno Haible <[email protected]> writes:
> Pádraig Brady wrote:
>> Solaris 11.4, SPARC-M8, 1 coreutils fail (cfarm216)
>> ...
>> Putting truss in the test shows the failure after vfork:
>>
>> vforkx(0) = 26169
>> lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) =
>> 0xFFBFFEFF [0xFFFFFFFF]
>> Incurred fault #5, FLTACCESS %pc = 0x100022468
>> siginfo: SIGBUS BUS_ADRALN addr=0xFFFF2F682F68772C
>> Received signal #10, SIGBUS [default]
>> siginfo: SIGBUS BUS_ADRALN addr=0xFFFF2F682F68772C
>
> Trouble with vfork on SPARC: not surprising. The "sliding register window"
> of the SPARC architecture is a beast to get correctly implemented in
> the kernel and in setjmp/longjmp. After vfork, the parent and the child
> are supposed to
> - share the memory,
> - but have distinct register sets.
> In other architectures this works reasonably, because the child process
> does only minimal changes to the memory contents before it exec()s.
> But on SPARC, due to the register window that can cause memory writes
> simply at subroutine invocation or return, this is very hairy.
Thanks for all the help testing Bruno. And for the analysis on this one
Pádraig.
I'm surprised this came up in the 'install' test and not 'sort', since in
'sort' we close and dup2 a few file descriptors. Which felt a bit hairy
given the old POSIX standardization of vfork [1]:
... the behavior is undefined if the process created by vfork()
either modifies any data other than a variable of type pid_t used to
store the return value from vfork(), or returns from the function in
which vfork() was called, or calls any other function before
successfully calling _exit() or one of the exec family of functions.
I left it since there is actual benefit to using vfork in 'sort', which
may use a lot of memory depending on the buffer size. For 'install',
there isn't much need for vfork.
>> * If I force ifdef out the VFORK call in gnulib's spawni it's OK
>> * If I force the use of the system posix_spawnp it's Ok. Tested with:
>> ./configure gl_cv_func_posix_spawnp_secure_exec=yes --quiet && gmake -j8
>> gmake TESTS=tests/install/basic-1.sh SUBDIRS=. check
>
> Interesting... I'll take a look.
>
>> Alternatively coreutils could force gnulib not to use vfork at all
>
> I would limit the workaround to SPARC, because of the discussion above.
Is there any other architectures other than SPARC we should worry about?
I'm not opposed to just disabling POSIX_SPAWN_USEVFORK. On recent glibc
systems we still get the benefits from using clone3 (..., CLONE_VM). On
older glibc and others, things should behave as they always did for the
most part.
Collin
[1] https://pubs.opengroup.org/onlinepubs/009696799/functions/vfork.html
