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

[Adam Farley8]

Hi David,

Thanks for your thoughts.

The user should absolutely have immediate feedback, yes, and I agree
that "skipping" paths could lead to us loading the wrong library.

Perhaps a compromise? We fire off a stderr warning if any of the paths 
are too long (without killing the VM), we ignore any path *after*
(and including) the first too-long path, and we kill the VM if the
first path is too long.

Warning message example: 

----
Warning: One or more sun.boot.library.path paths were too long
for this system, and it (along with all subsequent paths) have been 
ignored.
----

Another addition could be to check the path lengths for the property
sooner, thus aborting the VM faster if the default path is too long.

Assuming we posit that the VM will always need to load libraries.

Best Regards

Adam Farley 
IBM Runtimes


David Holmes <david.holmes at oracle.com> wrote on 01/07/2019 22:10:45:

> From: David Holmes <david.holmes at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, hotspot-dev at openjdk.java.net
> Date: 01/07/2019 22:12
> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path
> paths are longer than JVM_MAXPATHLEN
> 
> 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://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=cSTGBGkEsu5yl0haJ6it9egPSgixg7mRei6lBDB5Y3k&s=xZzQCnv68xd9hJyyK1obSim38eWSRmLPfuR__9ddZWg&e=
> > Webrev: https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021_webrev_&d=DwICaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=P5m8KWUXJf-
> 
CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=cSTGBGkEsu5yl0haJ6it9egPSgixg7mRei6lBDB5Y3k&s=-
> hKU0zUd_0LDT08wTilexgI54EeSgt8xUk97i6V63Bk&e= 
> > 
> > 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
> > 
> 

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