8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call

[Sciampacone, Ryan]

Hi Andrew, 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.

On 6/19/19, 3:03 AM, "jdk8u-dev on behalf of Andrew Dinn" <jdk8u-dev-bounces at openjdk.java.net on behalf of adinn at redhat.com> wrote:

    Could I please have reviews for the following patch against jdk8u-dev:
    
      Webrev: http://cr.openjdk.java.net/~adinn/8194653/webrev.00/
      JIRA:   https://bugs.openjdk.java.net/browse/JDK-8194653
    
    Background:
    
    The email threads discussing this issue were a tad inconclusive for both
    jdk8u and jdk9+.
    
    On jdk8 a suggestion was left hanging that a fix in the jdk not jvm
    might be better.
    
    On jdk9+ upwards the deadlock does not manifest but it might do in
    future so an investigation was requested by Alan Bateman which has not
    been followed up.
    
    Nevertheless, Oracle have applied a jdk8u patch in 8u212, although using
    a different JIRA issue.
    
      https://bugs.openjdk.java.net/browse/JDK-8222858
    
    I am not sure why this has been done as a backport? Note it may be
    relevant that the original JIRA (8194653) is marked as being against 8u231.
    
    Testing:
    
    The reproduced supplied with the original patch and included in the
    above webrev fails before applying and works afterwards.
    
    regards,
    
    
    Andrew Dinn
    -----------