Process.exec with the linux posix_spawn mode has a bug

[forax at univ-mlv.fr]

Thanks Thomas, 
by the way, what is the purpose of jexec ? 

Rémi 

> De: "Thomas Stüfe" <thomas.stuefe at gmail.com>
> À: "David Lloyd" <david.lloyd at redhat.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Samedi 11 Mai 2019 20:49:02
> Objet: Re: Process.exec with the linux posix_spawn mode has a bug

> Hi Remi,

> David is right - a few more details:
> In both fork- and vfork-mode we fork/vfork the child process and in the child
> process then exec() the target binary (in this case "java" itself).

> In posix_spawn mode, for complicated reasons, we start, via posix_spawn(), the
> jspawnhelper - which, depending on the glibc involved, will either vfork() or
> clone() the child process and then exec() the jspawnhelper binary. Then, inside
> the jspawnhelper, we will exec() a second time, this time the target binary.

> (So, small correction, we do not have an intermediate _process_ here - at any
> time only two processes are involved, the parent and the child - but inside the
> child we call exec() twice.)

> If you get EACCESS only in posix_spawn() mode, the only difference to fork/vfork
> is that we exec() jspawnhelper. That is a binary located in the jdk and should
> have the correct permissions set.

> If you have a reproducible scenario, can you strace the call? (you would
> probably need "strace -f", and if you see in the output the jspawnhelper path
> with either _vfork or _clone system calls it worked).

> Cheers, Thomas

> On Sat, May 11, 2019 at 5:15 PM David Lloyd < [ mailto:david.lloyd at redhat.com |
> david.lloyd at redhat.com ] > wrote:

>> On Sat, May 11, 2019 at 9:49 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>>> I've seen a weird error on my CI [1] since the 15th of February when using the
>> > jdk 13,
>> > i was not able to run jshell* using the programmatic API (java tool) anymore.

>>> Yesterday, i took the time to track that issue and i believe i've found the root
>>> cause, trying to execute the java launcher using ProcessBuilder.start() with
>>> the jdk 13 sometimes fails with an i/o exception (errno 13) which is weird
>>> because you are trying to execute the same process that the one you are
>>> executing. Note that this is a spurious bug, I was not able to find the exact
>> > condition that triggers that bug.
>> > So sometime it works, sometime it doesn't.

>> Assuming you're running on Linux (given that the changeset only
>> applies to Linux), errno 13 is EACCES which would indicate a
>> filesystem permission issue. Are you sure you have permission to
>> execute `jspawnhelper` in your JVM installation? Could there be an
>> SELinux restriction in place?

>> Here's what the man page says:

>> ```

>> [EACCES] Search permission is denied for a component of
>> the path prefix.

>> [EACCES] The new process file is not an ordinary file.

>> [EACCES] The new process file mode denies execute permission.

>> [EACCES] The new process file is on a filesystem
>> mounted with execution

>> disabled (MNT_NOEXEC in <sys/mount.h>).
>> ```

>>> If i pass -Djdk.lang.Process.launchMechanism=fork (or vfork) when starting the
>>> VM, the bug disappear meaning that the bug occurs when the VM is trying to use
>>> posix_spawn, perhaps spawn is trying to do an optimization when you try to
>> > execute the same process as the one you are running under some conditions ?

>> The posix_spawn approach executes an intermediate support process
>> (`jspawnhelper`) which in turn executes the target process. I believe
>> there's an extensive discussion on the reasons for this in the
>> `core-libs-dev` archive.

>> --
>> - DML