Losing features of JVM_Open, e.g. CLOEXEC

[frederic parain]

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: Frederic.Parain at oracle.com