Thanks Martin for the second review! I'll fix the close call and then I'll push.
Cheers, Thomas On Wed, Jun 5, 2019 at 8:35 AM Martin Buchholz <marti...@google.com> wrote: > Huh, looks like an ancient bug of mine that doesn't trigger in practice. > > Looks good, except change FAIL_FILENO to fail_pipe_fd below (that also > won't make a difference in practice) > > 386 close(FAIL_FILENO); > > > > On Tue, Jun 4, 2019 at 11:01 PM Thomas Stüfe <thomas.stu...@gmail.com> > wrote: > >> Hi Martin, >> >> can you quickly chime in on this, this is a very small patch and I'd like >> to get it from my table for JDK13. >> >> Thank you! >> >> ---------- Forwarded message --------- >> From: Thomas Stüfe <thomas.stu...@gmail.com> >> Date: Tue, Jun 4, 2019 at 3:23 PM >> Subject: RFR(xs): 8224181: On child process spawn, child may write to >> random file descriptor instead of the fail pipe >> To: Java Core Libs <core-libs-dev@openjdk.java.net> >> >> >> Hi all, >> >> may I please have reviews for this small fix: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224181 >> cr: >> http://cr.openjdk.java.net/~stuefe/webrevs/8224181-on-child-process-spawn--child-may-write-to-wrong-file-descriptor-instead-of-the-fail-pipe/webrev.00/webrev/ >> >> In sub process error handling code (WhyCantJonnyExec) child signals error >> to parent by writing an error code to the fail pipe. It does that using the >> hard wired fail pipe write-end fd (FAIL_FILENO, usually 4). But that only >> works as intended after the fail pipe write end has been successfully >> dup2'ed to FAIL_FILENO. >> >> If an error happens before that, error code will still be written to >> FAIL_FILENO, which may be an invalid file handle - which is almost benign - >> or refer to an unrelated file descriptor the child inherited and did not >> close yet - which is not good. >> >> Cheers, Thomas >> >
