Process.exec with the linux posix_spawn mode has a bug

[Thomas Stüfe]

I am happy this is resolved and the intermittent behavior explained. Yes,
we could improve exception messages, especially since analyzing fork
scenarios is cumbersome.

But as Alan wrote, this should not happen if the JFK is installed correctly.

Cheers, Thomas

On Sun, May 12, 2019, 10:23 AM <forax at univ-mlv.fr> wrote:

> 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 <david.lloyd at redhat.com>
> wrote:
>
>> On Sat, May 11, 2019 at 9:49 AM Remi Forax <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
>>
>
>