JDK-8217216 : Launcher does not defend itself against LD_LIBRARY_PATH_64 (Solaris)
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-01-16
  • Updated: 2019-03-14
  • Resolved: 2019-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13 b12Fixed
Related Reports
Relates :  
JDK-6367077 - Purge LD_LIBRARY_PATH usage from the launcher
Relates :  
JDK-4810347 - jvm STILL exec's itself twice if -d64 or -d32 is used to change data model
Relates :  
JDK-7029048 - (launcher) fence the launcher against LD_LIBRARY_PATH
Relates :  
JDK-8216532 - tools/launcher/Test7029048.java fails (Solaris)
Description
On Solaris, if you set LD_LIBRARY_PATH_64 then that completely overrides any setting of LD_LIBRARY_PATH. If the prevailing environment defines LD_LIBRARY_PATH_64 then the launcher tries to defend itself by prepending its preferred library paths to LD_LIBRARY_PATH, as implemented in the fix for JDK-7029048. That will, however, have no effect -- the launcher should, in this case, prepend its preferred paths to LD_LIBRARY_PATH_64.
Comments
Code review request: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058529.html
13-02-2019
FWIW, starting in JDK 5.0 (JDK-4810347) on Solaris the launcher correctly checked the trio of LD_LIBRARY_PATH, LD_LIBRARY_PATH_32, and LD_LIBRARY_PATH_64 back when the launched needed to re-exec to get the runpath set correctly. The changes in JDK-6367077 removed this behavior.
16-01-2019