PING: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

[Thomas Stüfe]

Hi Florian,

Interesting, but in this case it is not posix_spawn, but plain fork(). The
VM does this, the exec calls come from us, not the libc. See childproc.c .

Cheers, Thomas’

On Tue 4. Jun 2019 at 22:42, Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas Stüfe:
>
> > Then I ran an strace over it and saw this:
> >
> > 5332 [pid  3911] execve("./sleep2", ["./sleep2"], [/* 78 vars */]
> <unfinished ...>
> >
>                      ..
> > 5342 [pid  3911] <... execve resumed> )      = -1 ENOEXEC (Exec format
> error)
> > 5343 [pid  3911] execve("/bin/sh", ["/bin/sh", "./sleep2"], [/* 78 vars
> */] <unfinished ...>
> > 5347 [pid  3911] <... execve resumed> )      = 0
> >
> > So, if the first exec fails for whatever reason, we try again, passing
> the executable file name
> > as argument to the system shell. This does not feel right? Do you know
> why we do this?
>
> What's your glibc version?  Unless it's ancient, this is probably this
> bug:
>
>   <https://sourceware.org/bugzilla/show_bug.cgi?id=23264>
>
> I don't know why this behavior was part of the initial implementation of
> posix_spawn.  It was subsequently removed for new binaries, but came
> back as a regression (the bug I referenced).
>
> Thanks,
> Florian
>