My bad. I missed the FD_CLOEXEC flag added by os::open() when I replaced JVM_Open with open in zip native code.
However, I still think that removing those interfaces was a good move. But I understand that the change it introduces with zip file descriptors is an issue. Reverting the changeset to re-introduce JVM_Open is not a solution. Maintaining a VM interface only adding a flag for only 2 call sites doesn't make sense to me. Either the file descriptor leak issue is specific to the zip package and can be fixed locally. Or the issue impacts more native code and adding an infrastructure to libjava should be discussed. Quickly grepping the code, I found many naked calls to open, but only one use of FD_CLOEXEC. Further investigations would be required to track potential file descriptor leaks in all libraries. Did you create a bug to track this issue yet? Regards, Fred On 30/10/2014 18:15, Martin Buchholz wrote:
Here's the state of the world: - the Unix designers made a design mistake that file descriptors are inherited by subprocesses by default. - all library code (almost all the code in the universe, including the JDK) needs to coexist with foreign code that might fork+exec at any time - to ensure that file descriptors don't leak into subprocesses, (almost) all library calls that create file descriptors must ensure that they have the close-on-exec bit set. (yes, this has been broken for a long time) - this is difficult enough that all creations of file descriptors must be wrapped using some kind of common infrastructure - JVM_Open (aka os::open) was terrible infrastructure (essentially undocumented) but at least it *was* infrastructure - we need openjdk-level or at least core-libraries-level native infrastructure, a place to put things like os::open and readFully. A project-wide commitment
-- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: [email protected]
