8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call
Sciampacone, Ryan
sci at amazon.com
Thu Jun 20 14:35:06 UTC 2019
Yes, we're looking at options, but are also very much open to suggestions!
The issue is having the path validity detection affect <clinit> code which ultimately results in classes never being loadable again. We've considered just going after the problematic class/load library combinations (in this case prime things with something like sun.nio.fs.UnixNativeDispatcher directly) but then this becomes per platform specific choices. Not exactly pretty - but it would solve the issue.
If you have other ideas let us know.
On 6/19/19, 9:41 AM, "Andrew Dinn" <adinn at redhat.com> wrote:
Hi Ryan,
On 19/06/2019 16:40, Sciampacone, Ryan wrote:
> We've discovered that there's a hidden problem with that fix.
>
> If an "invalid" "user.dir" property is set (e.g., not absolute -
> leading with a "/" in *nix) then the fix results in an exception
> throw. During startup, this unhandled exception throw means the JVM
> will fail out / crash in a controlled fashion. Wrapping the
> initialization in a catch-and-clear mechanism means that the classes
> involved have failed to load, and so subsequent access gives a
> different Java exception than what they would have gotten normally
> (ie: the malformed user.dir exception).
>
> Scripts etc that had an invalid -Duser.dir on the command line could
> potentially run without issues. With this fix, they'll now crash on
> startup - and the error message isn't obvious.
>
> More work is required.
Ok, thanks for the heads up.
Are you/Amazon currently working on a better fix?
If so do you know when it is likely to be ready?
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the jdk8u-dev
mailing list