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.
FAIL: test7029048, Case 3: LD_LIBRARY_PATH should be set
expected 4 but got 3
Fix Request (11u)
This improves the test reliability and matches `11.0.13-oracle`. Patch applies to 11u cleanly, passes tools/launcher tests.
The fix for JDK-8210669 enabled some tests to run that had not been running, and perhaps had never run.
Amongst these tests was tools/launcher/Test7029048.java, which is meant to ensure that the Java launcher defends itself against interfering settings of the LD_LIBRARY_PATH environment variable, as implemented in the fix for JDK-7029048.
It took me quite a while to understand exactly what this test was doing, but in the end the root cause was that the test could not distinguish between an LD_LIBRARY_PATH value that���s empty from one that contains just a single path. This is important on Solaris, where the test also checks that setting LD_LIBRARY_PATH_64 does not interfere with the launcher. In this context the environment variable can contain either no path or just one path, depending upon which case is being tested.
I fixed this accounting problem and, while I was at it, made a few other changes to clarify the test for future maintainers.
In a cruel twist of fate, it turns out that the behavior implemented for 7029048, and verified by this test, is incorrect. On Solaris, if you set LD_LIBRARY_PATH_64 then that completely overrides any setting of LD_LIBRARY_PATH. The launcher tries to defend itself against a setting of LD_LIBRARY_PATH_64 by setting LD_LIBRARY_PATH, but that will have no effect -- it should really set LD_LIBRARY_PATH_64. I���ve filed JDK-8217216 to record this.
Adding maintainer-pain label since this failure has been seen in every tier 4 run since jdk13-jdk.108 in January 10.
Tier 4 failure in all CI's - bumped to P3. Should be fixed or excluded.
There were four new changes in the CI job. JDK-8210669 seems like the one most likely to have caused this.