RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN

[David Holmes]

Hi Adam,

On 1/07/2019 10:27 pm, Adam Farley8 wrote:
> Hi All,
> 
> The title say it all.
> 
> If you pass in a value for sun.boot.library.path consisting
> of one or more paths that are too long, then the vm will
> fail to start because it can't load one of the libraries it
> needs (the zip library), despite the fact that the VM
> automatically prepends the default library path to the
> sun.boot.library.path property, using the correct separator
> to divide it from the user-specified path.
> 
> So we've got the right path, in the right place, at the
> right time, we just can't *use* it.
> 
> I've fixed this by changing the relevant os.cpp code to
> ignore paths that are too long, and to attempt to locate
> the needed library on the other paths (if any are valid).

As I just added to the bug report I have a different view of "correct" 
here. If you just ignore the long path and keep processing other short 
paths you may find the wrong library. There is a user error here and 
that error should be reported ASAP and in a way that leads to failure 
ASAP. Perhaps we should be more aggressive in aborting the VM when this 
is detected?

David
-----

> I've also added functionality to handle the edge case of
> paths that are neeeeeeearly too long, only for a
> sub-path (or file name) to push us over the limit *after*
> the split_path function is done assessing the path length.
> 
> I've also changed the code we're overriding, on the assumption
> that someone's still using it somewhere.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8227021
> Webrev: http://cr.openjdk.java.net/~afarley/8227021/webrev/
> 
> Thoughts and impressions welcome.
> 
> Best Regards
> 
> Adam Farley
> IBM Runtimes
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>