On Thu, Oct 30, 2014 at 6:08 AM, Alan Bateman <[email protected]> wrote: > The change in behavior from JVM_Open ito open was missed but there is a long > way to go in JDK 9 so lots of time to fix the issue (if there is an issue).
The changes to zip file file descriptors is just the one most visible to me. > As was noted in one of the replies, the only usages of JVM_Open were in the > zip code, it hasn't been used consistently used in the libraries for at > least 10+ years. When doing significant changes then thorough code reviews > are important but good tests are equally, and sometimes more, important. I > understand that having a test for the O_CLOEXEC might be too hard so I'm > interested to know how you ran into it. Maybe it was inspection? My hobby is running strace on the JDK and counting the fds with close-on-exec flag. I noticed that the calls to fcntl(...FD_CLOEXEC) had disappeared! You're unlikely to get bug reports because of the action-at-a-distance non-debuggability. > Maybe an > app that opens lots of zip files and executes fork/exec itself? For > ProcessBuilder and Runtime.exec usages then the I thought the childproc code > handled this by looping over the open file descriptors and closing them. So > even if O_CLOEXEC or fcntl(FD_CLOEXEC) isn't used then it should be closed > in the child. In general, Java is just a guest inside some Unix process, and should be well-behaved. > As to whether we need a JVM_Open replacement in libjava then maybe we do but > I think it needs a discussion as to whether the JDK really needs a porting > interface or just useful infrastructure. Also I think going forward then I > assume that the amount of native code will reduce, particularly when FFI > comes along and we start to get rid of some of the native code (at least I > hope that happens). I think it will just become more convenient to call the native code. Perhaps the common infrastructure can be written in Java, but it should still exist. > In the mean-time then I think I'd like to understand more as to whether the > O_CLOEXEC is an issue or not. Aside from the zip code then I don't think > we've been using it consistently so I'm wondering if the issue is some > native code calling fork+exec or something else? Yes. All broken since forever. I'm focused on close-on-exec, but there's also restartable system calls to consider. And partial reads ...
