Re: 4.3.90 release candidate segfaults on linux and solaris

[Martin Dorey]

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 <psmith@gnu.org>
Sent: Sunday, September 25, 2022 06:23
To: Martin Dorey <Martin.Dorey@hitachivantara.com>; Denis Excoffier <bug-tar@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="">

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__ */