Thanks Thomas, by the way, what is the purpose of jexec ? Rémi
> De: "Thomas Stüfe" <thomas.stu...@gmail.com> > À: "David Lloyd" <david.ll...@redhat.com> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "core-libs-dev" > <core-libs-dev@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.ll...@redhat.com > | > david.ll...@redhat.com ] > wrote: >> On Sat, May 11, 2019 at 9:49 AM Remi Forax < [ mailto:fo...@univ-mlv.fr | >> fo...@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
