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