JDK11 tests fail on Alpine 314 machine using JDK21 as the default java

[Haroon-Khel]

All of the tests kicked off in https://ci.adoptium.net/view/Test_grinder/job/AQA_Test_Pipeline/235/console on test-docker-alpine314-x64-1 fail with the following error

19:20:49  (ant -f ./scripts/build_tools.xml -DTEST_JDK_HOME=/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/jdkbinary/j2sdk-image -DTEST_ROOT=/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/.. -DLIB_DIR=/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/../../testDependency/lib 2>&1; echo $? ) | tee "/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation/compilation.log"; \
19:20:49  if [ -z "$(tail -1 /home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation/compilation.log | grep 0)" ]; then perl scripts/moveDmp.pl --compileLogPath="/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation/compilation.log" --testRoot="/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/.."; false; else rm -f -r "/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation"; fi
19:20:49  Exception in thread "main" java.lang.NoSuchMethodError: getMainType
19:20:49  1
19:20:49  make: *** [makefile:105: compileTools] Error 1

Changing the default JDK to JDK11 fixes this issue. First noticed in the JDK11 aqa triage of the April 2024 release adoptium/aqa-tests#5232 (comment)

[Haroon-Khel]

At the moment all of our Alpine static docker containers use JDK21 as their default java

[sxa]

Just a thought - I'm nervous that this means it's doing something like picking up a JDK21 java executable but using a library path that's forcing it to pick up some of the libraries from an earlier JRE that doesn't have that symbol.

[Haroon-Khel]

Fails on Alpine 320 aswell https://ci.adoptium.net/job/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/310/console running on https://ci.adoptium.net/computer/test-docker-alpine320-x64-1/

compileLogPath="/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation/compilation.log" --testRoot="/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/.."; false; else rm -f -r "/home/jenkins/workspace/Test_openjdk11_hs_extended.functional_x86-64_alpine-linux/aqa-tests/TKG/../TKG/output_compilation"; fi
11:46:26  Exception in thread "main" java.lang.NoSuchMethodError: getMainType
11:46:26  1
11:46:26  make: *** [makefile:114: compileTools] Error 1

[Haroon-Khel]

Any remaining x64 alpine machines that were not using JDK11 as their default java are now using JDK11. This is to prevent JDK11 test failures during the release period while this issue remains unsolved

[smlambert]

Related: adoptium/aqa-tests#5425

[jiekang]

Related: Sophia's comment #2934 (comment)

and comment in code:
https://github.com/openjdk/jdk11u/blob/master/src/java.base/unix/native/libjli/java_md_solinux.c#L369

     * The musl library loader requires LD_LIBRARY_PATH to be set in order
     * to correctly resolve the dependency libjava.so has on libjvm.so.

Maybe unsetting LD_LIBRARY_PATH is not the right workaround for 11+

[sxa]

This looks like the same issue as before - LD_LIBRARY_PATH is being set by the JDK which is impacting other JDks which are spawned. Test case:
exec.tar.gz:
If you have a 21 and 11 available and set the environment variable like this you get the failure:

/ # LD_LIBRARY_PATH=/jdk-21.0.3+9/lib/server:/jdk-21.0.3+9/lib:/jdk-21.0.3+9/../lib jdk-11.0.23+9-jre/bin/java exec
Exception in thread "main" java.lang.NoSuchMethodError: getMainType
/ # 

Maybe unsetting LD_LIBRARY_PATH is not the right workaround for 11+
It ought to work ok - there is no end user requirement to set the variable to anything before running the JVM that I've noticed.

As per @jiekang's comment in a recent call I'm suspicious that the fix in https://github.com/adoptium/aqa-tests/pull/5430/files hasn't taken effect as expected based on the presence of the LD_LIBRARY_PATH variable in the test log

[sxa]

I'm suspicious that the fix in https://github.com/adoptium/aqa-tests/pull/5430/files hasn't taken effect as expected

I've made a review comment on Haroon's PR - there are three instances of that code in the JenkinsfileBase and only one has been changed. Adding the same fix for the others resolves the problem.

Noting that the presence of the LD_LIBRARY_PATH in the log is presumably because it's doing that at https://github.com/adoptium/aqa-tests/blob/b02fb821e5cef4f9b309311a06b95cd94ff0a297/buildenv/jenkins/JenkinsfileBase#L177 and will therefore not be subject to the LD_LIBRARY_PATH squashing done specifically when executing other sh calls in the file.

[jiekang]

Related: Sophia's comment #2934 (comment)

and comment in code: https://github.com/openjdk/jdk11u/blob/master/src/java.base/unix/native/libjli/java_md_solinux.c#L369

     * The musl library loader requires LD_LIBRARY_PATH to be set in order
     * to correctly resolve the dependency libjava.so has on libjvm.so.

Maybe unsetting LD_LIBRARY_PATH is not the right workaround for 11+

Ignore the maybe part. The JDK code will set LD_LIBRARY_PATH to something that works by itself, along with any user supplied path appended to it.

[Haroon-Khel]

Any remaining x64 alpine machines that were not using JDK11 as their default java are now using JDK11. This is to prevent JDK11 test failures during the release period while this issue remains unsolved

The default jdk on our x64 alpine boxes has been changed back to 21 to test the fix at adoptium/aqa-tests#5430

[Haroon-Khel]

Can be closed now that adoptium/aqa-tests#5430 is merged

[jiekang]

@Haroon-Khel FYI in the future if your PR has one of the keywords mentioned in [1] it will auto-close the issue for you.

[1]
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue