On 30/10/2014 19:42, Martin Buchholz wrote:
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
Hi Frederic,
On Thu, Oct 30, 2014 at 10:54 AM, frederic parain
wrote:
> 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 i
On Oct 30, 11:26am, marti...@google.com (Martin Buchholz) wrote:
-- Subject: Re: Losing features of JVM_Open, e.g. CLOEXEC
| On Thu, Oct 30, 2014 at 10:52 AM, Mario Torre
| wrote:
| > Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
| > can make a reasonable test
On Thu, Oct 30, 2014 at 10:52 AM, Mario Torre
wrote:
> Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
> can make a reasonable test though.
Mario, I'm not sure what you mean.
Even if we can find and inspect each fd, and even if we knew the
stacktrace of where every fd was
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
Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
can make a reasonable test though.
Cheers,
Mario
2014-10-30 18:30 GMT+01:00 Martin Buchholz :
> On Thu, Oct 30, 2014 at 3:24 AM, Mario Torre
> wrote:
>> I've been thinking perhaps one can use fcntl to check what flags are
>>
On Thu, Oct 30, 2014 at 3:24 AM, Mario Torre
wrote:
> I've been thinking perhaps one can use fcntl to check what flags are
> passed given we can retrieve all the file descriptors that have been
> opened?
It's possible to find all the open file descriptors (e.g. using
/proc/self/fd), but they may
On Thu, Oct 30, 2014 at 6:08 AM, Alan Bateman 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
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
On 29/10/2014 20:12, Martin Buchholz wrote:
Hi guys,
In your change
805: Cleanup of old and unused VM interfaces
you have made changes like this:
-zfd = JVM_Open(path, flag, 0);
+zfd = open(path, flag, 0);
throwing away use of old shared infrastructure and replaci
I've been thinking perhaps one can use fcntl to check what flags are
passed given we can retrieve all the file descriptors that have been
opened?
Using raw open complicates the matter though.
Cheers,
Mario
2014-10-30 11:16 GMT+01:00 Mario Torre :
> This is exactly what I was about to reply. One
This is exactly what I was about to reply. One can only spot those
things if there is a standardised API, and even in this case it's not
at all easy. That doesn't stop from trying :) but removing the API was
likely a mistake, which would not be a terrible one because of what
David points, except th
On 30/10/2014 6:46 PM, Alan Bateman wrote:
On 29/10/2014 21:15, Mario Torre wrote:
+1
We should have spotted it in the review though.
We should but the ultimate rat catcher should be the tests, it's
possible that we have a hole there.
Not sure how the presence or absence of CLOEXEC would
On 29/10/2014 21:15, Mario Torre wrote:
+1
We should have spotted it in the review though.
We should but the ultimate rat catcher should be the tests, it's
possible that we have a hole there.
chholz) wrote:
-- Subject: Losing features of JVM_Open, e.g. CLOEXEC
| throwing away use of old shared infrastructure and replacing with "naked"
| calls to the OS. Although understandable, this abandons benefits of
using
| shared infrastructure. Here I'm thinking of the close-on-exe
+1
We should have spotted it in the review though.
Cheers,
Mario
Il 29/ott/2014 21:47 "Christos Zoulas" ha scritto:
> On Oct 29, 1:12pm, marti...@google.com (Martin Buchholz) wrote:
> -- Subject: Losing features of JVM_Open, e.g. CLOEXEC
>
> | throwing away use of old
On Oct 29, 1:12pm, marti...@google.com (Martin Buchholz) wrote:
-- Subject: Losing features of JVM_Open, e.g. CLOEXEC
| throwing away use of old shared infrastructure and replacing with "naked"
| calls to the OS. Although understandable, this abandons benefits of using
| shared infr
Hi guys,
In your change
805: Cleanup of old and unused VM interfaces
you have made changes like this:
-zfd = JVM_Open(path, flag, 0);
+zfd = open(path, flag, 0);
throwing away use of old shared infrastructure and replacing with "naked"
calls to the OS. Although und
18 matches
Mail list logo
