AArch64 openjdk LambdaFileEncodingSerialization assertion failure

[knn-k]

java/lang/invoke/lambda/LambdaFileEncodingSerialization.java fails intermittently.

Failure link

• https://ci.adoptopenjdk.net/job/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/25/ (on build-docker-ubuntu1804-armv8-4)
• https://ci.adoptopenjdk.net/job/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/24/ (on build-docker-fedora33-armv8-5)
• https://ci.adoptopenjdk.net/job/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/23/ (on build-docker-fedora33-armv8-2)
• https://ci.adoptopenjdk.net/job/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/21/ (on build-docker-ubuntu1804-armv8-3)

The test ran successfully in Build 22 (on test-packet-ubuntu1604-armv8-1).
The failure is observed also with XL builds. https://ci.adoptopenjdk.net/job/Test_openjdk16_j9_sanity.openjdk_aarch64_linux_xl/

Optional info

• intermittent failure: yes

Failure output (captured from console output)

[2021-02-08T17:39:42.837Z] test LambdaFileEncodingSerialization.testDeserializeLambdaEncoding(): failure
[2021-02-08T17:39:42.838Z] java.lang.AssertionError: Command /home/jenkins/workspace/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/openjdkbinary/j2sdk-image/bin/javac -J-Dfile.encoding=ISO-8859-1 -cp . -d . /home/jenkins/workspace/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/openjdk-tests/openjdk/openjdk-jdk/test/jdk/java/lang/invoke/lambda/TestLambdaFileEncodingSerialization.java , failed exitCode = 1 expected [true] but found [false]
[2021-02-08T17:39:42.838Z] 	at org.testng.Assert.fail(Assert.java:94)
[2021-02-08T17:39:42.838Z] 	at org.testng.Assert.failNotEquals(Assert.java:496)
[2021-02-08T17:39:42.838Z] 	at org.testng.Assert.assertTrue(Assert.java:42)
[2021-02-08T17:39:42.838Z] 	at LambdaFileEncodingSerialization.testDeserializeLambdaEncoding(LambdaFileEncodingSerialization.java:64)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[2021-02-08T17:39:42.838Z] 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
[2021-02-08T17:39:42.838Z] 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
[2021-02-08T17:39:42.838Z] 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
[2021-02-08T17:39:42.838Z] 	at org.testng.TestRunner.run(TestRunner.java:623)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
[2021-02-08T17:39:42.838Z] 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
[2021-02-08T17:39:42.838Z] 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
[2021-02-08T17:39:42.838Z] 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
[2021-02-08T17:39:42.838Z] 	at org.testng.TestNG.run(TestNG.java:1018)
[2021-02-08T17:39:42.838Z] 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
[2021-02-08T17:39:42.838Z] 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[2021-02-08T17:39:42.838Z] 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
[2021-02-08T17:39:42.838Z] 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
[2021-02-08T17:39:42.838Z] 	at java.base/java.lang.Thread.run(Thread.java:853)

[knn-k]

This could be an environment-dependent problem.

• Rerun on build-docker-fedora33-armv8-3: Failed (https://ci.adoptopenjdk.net/job/Grinder/6607/)
• Rerun on test-packet-ubuntu1604-armv8-1: Passed (https://ci.adoptopenjdk.net/job/Grinder/6616/)

[Akira1Saitoh]

javac launched from the test case fails to write a class file.

[2021-02-08T17:39:42.837Z] /home/jenkins/workspace/Test_openjdk16_j9_sanity.openjdk_aarch64_linux/openjdk-tests/openjdk/openjdk-jdk/test/jdk/java/lang/invoke/lambda/TestLambdaFileEncodingSerialization.java:38: error: error while writing ABC???: bad filename RelativeFile[TestLambdaFileEncodingSerialization$ABC???.class]
[2021-02-08T17:39:42.837Z] public static class ABC???? implements Serializable {

https://github.com/ibmruntimes/openj9-openjdk-jdk16/blob/f7d23fa5a1bfa38580ecb4ee20d40f22d5bc5267/test/jdk/java/lang/invoke/lambda/TestLambdaFileEncodingSerialization.java#L38

[knn-k]

So it fails to convert the class name to a file name in UTF-8, depending on the environment. Perhaps a locale problem?

[knn-k]

I cannot recreate the failure locally even when I change the locale to a non-UTF-8 one.

[sxa]

Possibly related: We saw this on some of the docker containers in particular when we started using them: adoptium/aqa-tests#2138 (comment). It's possibly it requires some extra packages to be on the machine to work in other environments - our docker test images are (deliberately) quite minimal

[knn-k]

I have seen a similar problem before in an Linux environment that had no UTF-8 locales.
That is why I thought it could be related to locales.

[sxa]

Yep - almost certainly :-)

Do we know what the minimum set is that would allow it to work?

[knn-k]

Set LANG to any one of UTF-8 locales, such as C.UTF-8 or en_US.UTF-8. The locale needs to be available in the docker environment, of course.
I suppose that is the minimum for making file name encoding conversion (Java internal <--> UTF-8) work.

[sxa]

Was more interested if there was a particular package locale we could install that would make it work out of the box on our systems - I suppose the ideal option would be if the test suites to set themselves to one of those two before executing :-)

[adamfarley]

It looks like this issue occurs on Hotspot too: https://trss.adoptopenjdk.net/output/test?id=601ea2ce217ed804cc8a6d6a

[sxa]

@andrew-m-leonard This looks like the issue mentioned at openjdk that you had a patch for. Did it land?

[EDIT: Ignore that - resolved by the change to the static containers referenced below]