https://docs.oracle.com/cd/E88353_01/html/E37841/execvpe-2.html alleges to document Oracle Solaris 11.4 and appears to support execvpe. Yes, it's listed in Linux pages as a GNU extension and it's not on the Open Group page for the exec family, but symmetry makes it quite an obvious extension. Perhaps that could be detected by a configure test.
The Linux page for vfork, but not the Open Group one, says that vfork suspend the caller until the exec is done, so the caller could restore environ after. I don't immediately see that it could hurt and should fix it for Linux. Or there's copying the environment somewhere else. Huh, even just the environ pointer. ________________________________ From: Bug-make <bug-make-bounces+martin.dorey=hds....@gnu.org> on behalf of Martin Dorey <martin.do...@hitachivantara.com> Sent: Sunday, September 25, 2022 07:09 To: psm...@gnu.org <psm...@gnu.org>; Denis Excoffier <bug-...@denis-excoffier.org> Cc: bug-make@gnu.org <bug-make@gnu.org> Subject: Re: 4.3.90 release candidate segfaults on linux and solaris execvpe does indeed fix it for me. Undoing the fix again, doing make clean -k and coming out of the chroot to configure --disable-posix-spawn for my 64 bit root environment (with libc 2.24 from Debian Stretch on Linux 4.9.0-19-amd64), I can reproduce the problem again with this makefile. I'd be surprised if that doesn't crash for Paul too because I suggest that the kernel version isn't actually important either. ________________________________ From: Paul Smith <psm...@gnu.org> Sent: Sunday, September 25, 2022 06:23 To: Martin Dorey <martin.do...@hitachivantara.com>; Denis Excoffier <bug-...@denis-excoffier.org> Cc: bug-make@gnu.org <bug-make@gnu.org> Subject: Re: 4.3.90 release candidate segfaults on linux and solaris ***** EXTERNAL EMAIL ***** On Sun, 2022-09-25 at 06:02 +0000, Martin Dorey wrote: > And vfork is where that happens. If I’ve followed the thicket of > #ifdef correctly and understood the vfork man page, then this is > illegal when using vfork: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmirror%2Fmake%2Fblob%2Fmaster%2Fsrc%2Fjob.c%23L2556&data=05%7C01%7CMartin.Dorey%40hitachivantara.com%7C82c25851389d4e1c12cb08da9ef91def%7C18791e1761594f52a8d4de814ca8284a%7C0%7C0%7C637997090043171790%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=v9hASQYmLkyN49Vpvk4DGrT0roD482%2FC5uIyc3V2DLQ%3D&reserved=0 It's long past time to rewrite this entire part of job.c but I don't want to do that before the release. I did try this with a 32bit Ubuntu 14.04 docker container image which uses a similar libc version, but contrary to my previous assertion (sorry Denis!) if it's an issue with vfork then it IS related to the kernel version and so my docker containers won't be of any use. This is not an actual fix (won't work on Solaris obviously since execvpe() is a GNU extension) but can you try this change to see if it works on your system Martin? At least we can verify that this is the issue: diff --git a/src/job.c b/src/job.c index d12a9138..0a4ddae8 100644 --- a/src/job.c +++ b/src/job.c @@ -2553,8 +2553,7 @@ exec_command (char **argv, char **envp) # else /* Run the program. */ - environ = envp; - execvp (argv[0], argv); + execvpe (argv[0], argv, envp); # endif /* !__EMX__ */
