In posix_spawn mode, failing to exec() jspawnhelper may not result in an error

java.lang.Process uses posix_spawn() by default now on Linux too. That exposes a quirk/bug/depending-how-you-see-it in the glibc.

posix_spawn() does start a new child process with whatever method it likes - in case of glibc, with fork(), vfork() or clone() depending on the glibc version - then, in the child process, proceeds to exec() the target binary. In our case the target binary is always the jspawnhelper binary from the JDK.

The problem is that the glibc version of posix_spawn() does not report back an error if the exec() step fails. Instead, the child process will just quit with error code 127.

Strictly speaking that is no bug since POSIX allows that. But for us this situation is indistinguishable from a user program exiting with 127. If we fail to exec() the jspawnhelper, we need to raise an IOException. If a user program exits with 127, we do not care - user should handle this.

In our case this only affects the first exec() the child process does, execing the jspawnhelper. The jspawnhelper then will proceed to exec() the target binary, and we have error reporting for that in place.

But if the jspawnhelper cannot be exec()'ed - e.g. because its permissions are forbidding execution - currently, on glibc, we will not get an error. From the outside it looks like the child process quits immediately.

See also associated glibc discussion here:

https://sourceware.org/bugzilla/show_bug.cgi?id=18433