AdoptOpenJDK/TSC

JDK 11u and 8u October 2020 CPU respins

jerboaa opened this issue · 49 comments

jerboaa commented

A serious regression has been identified in one of the fixes pushed with the security patches from the October CPU which can crash the JVM. Upstream JDK 11u and 8u will do interim releases.

Details:

JDK 11: JDK-8250861, hotspot only change, called 11.0.9.1+1. Tag
JDK 8: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/012953.html, called 8u275-b01. No tag yet.

sxa commented

Checklist / stuff to consider:

  • RPM/YUM installers
  • DEB/APT installers
  • MSI installers
  • Homebrew installer
  • Dockerhub
  • API (inc. links from Andrew in the previous comment)
  • Downstream consumers such as gradle / chocolatey / sdkman etc.
aahlenst commented

8u275 isn't a problem for any Linux package. We handled that before. 11 is more of a concern. But because I currently do the version numbering by hand and our users don't really look at those (as long as they just get a new package), I plan to do something that's not dangerous like bumping the Adopt build number or call it 11.0.9+12.

[For the curious people: RPM sees 11.0.9+11 as 110911 and 11.0.9.1+1 as 110911 which are equal. Adding things at the end might have unforeseen consequences in the future because for RPM the longest wins.]

  • 👀1
jerboaa commented

I plan to do something that's not dangerous like bumping the Adopt build number or call it 11.0.9+12.

That sounds reasonable to me. Here is a PR for fedora and what we do:
https://src.fedoraproject.org/rpms/java-11-openjdk/pull-request/103

andrew-m-leonard commented

so we map 11.0.9.1+1 to 11.0.9+12 ?
So how about this for a "fudge", we simply tag that github level in our mirror with jdk-11.0.9+12 => https://github.com/AdoptOpenJDK/openjdk-jdk11u/releases/tag/jdk-11.0.9.1%2B1
It would mean Adopt is calling this level jdk-11.0.9+12...

aahlenst commented

@jerboaa Thanks for the pointer. That's indeed another possibility that we have.

@andrew-m-leonard I like calling it 11.0.9+12 best. AFAIK that what would have happened if upstream would not have released +11 and it requires zero adjustments on our side. And for Adoptium, we can start incorporating the 5 level version scheme and consider inventing our own versioning scheme like Azul does with Zulu. That would future-proof us.

sxa commented

Hmmm our existing own versioning scheme already allows point releases for bug fixes. To me 11.0.9+12 sounds, well, inacurrate so if we didn't want to incorporate the .1 directly after 11.0.9 we should perhaps make it a normal adopt point release called 11.0.9+11

(To be clear, I'd rather upstream had released as 11.0.9+12 but I'm not convinced making up that number would be a great move)

aahlenst commented

Doing a .2 (we already have a .1 for 11.0.9+11 on x64 and aarch64) is fine for me, too. And we know for sure that it works because we've done so in the past.

sxa commented

Current plan is to attempt to publish with a semver value of 11.0.9+11.2. The java -version output will have the 11.0.9.1+1 name and that should also be what the release shows up as in github. Only people looking carefully at the values from the API should notice. This was considered the best option for avoiding requiring potentially risky changes to the API being required for now while retaining the best visibility of the 11.0.9.1+1 name (Our preference would have been for upstream openjdk to release as 11.0.9+12 but we are where we are ;-) )

Sample metadata from @andrew-m-leonard 's test build:

14:52:53      "version": {
14:52:53          "minor": 0,
14:52:53          "patch": 1,
14:52:53          "security": 9,
14:52:53          "pre": null,
14:52:53          "adopt_build_number": 2,
14:52:53          "major": 11,
14:52:53          "version": "11.0.9.1+1-202011061432",
14:52:53          "semver": "11.0.9+11.2.202011061432",
14:52:53          "build": 1,
14:52:53          "opt": "202011061432"
14:52:53      },

Those changes were implemented under adoptium/temurin-build#2212.
The new pipelines have been initiated at:

andrew-m-leonard commented

Solaris:
Still won't build:

12:15:29  Undefined			first referenced
12:15:29   symbol  			    in file
12:15:29  Java_jdk_internal_platform_cgroupv1_Metrics_isUseContainerSupport

Arm:
Aarch64:
https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah does not have build jdk8u275-b01, is it not affected?

12:29:35  checkoutRequiredCodeToBuild:
12:29:35    workspace = /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-arm-hotspot/workspace/./build//src
12:29:35    BUILD_VARIANT = hotspot
12:29:35    TAG = jdk8u275-b01
12:29:35    BRANCH = dev
12:29:36  Checking out tag jdk8u275-b01
12:29:37  fatal: Couldn't find remote ref refs/tags/jdk8u275-b01
12:29:37  Failed cmd: git fetch origin "refs/tags/jdk8u275-b01:refs/tags/jdk8u275-b01"
12:29:37  WARNING: Cannot get tag due to previous failures. /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-arm-hotspot/workspace/target//metadata/scmref.txt will NOT be created!
12:29:37  checkoutRequiredCodeToBuild failed rc=128

Win:

ERROR: [WS-CLEANUP] Cannot delete workspace: Unable to delete 'E:\workspace\build-scripts\release\sign_build'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
ERROR: Cannot delete workspace: Unable to delete 'E:\workspace\build-scripts\release\sign_build'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
andrew-m-leonard commented

Win64 and zLinux re-submitted as build failed/artifact not stored:
https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1352/

andrew-m-leonard commented

x64Linux:
sanity.openjdk:
https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.openjdk_x86-64_linux/579/console

12:33:41    java/math/BigInteger/LargeValueExceptions.java
12:33:41  
12:33:41  #
12:33:41  # There is insufficient memory for the Java Runtime Environment to continue.
12:33:41  # Native memory allocation (mmap) failed to map 414187520 bytes for committing reserved memory.
12:33:41  # An error report file with more information is saved as:
12:33:41  # /home/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-64_linux/openjdk-tests/TKG/test_output_16049249143009/jdk_math_0/work/scratch/0/hs_err_pid23759.log
12:33:41  STDERR:
12:33:41  OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000007a5c00000, 414187520, 0) failed; error='Cannot allocate memory' (errno=12)

Re-run grinder: https://ci.adoptopenjdk.net/job/Grinder/4605/ Passed

win32:
sanity.openjdk:
https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/303/
com/sun/jdi/PrivateTransportTest.sh.PrivateTransportTest (from com_sun_jdi_PrivateTransportTest.sh)

12:51:18  JDK under test is: C:/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdkbinary/j2sdk-image
12:51:18  Setup private transport library by copying an existing one and renaming
12:51:18  cp C:/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdkbinary/j2sdk-image/jre/bin/dt_socket.dll /cygdrive/c/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdk-tests/TKG/test_output_16049249488111/jdk_jdi_0/work/classes/com/sun/jdi/private_dt_socket.dll
12:51:18  PATH=/cygdrive/c/Program Files/AdoptOpenJDK/jdk-8.0.272.10-hotspot/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program Files/Microsoft SQL Server/110/Tools/Binn:/cygdrive/c/Program Files (x86)/Microsoft SDKs/TypeScript/1.0:/cygdrive/c/Program Files/Microsoft SQL Server/120/Tools/Binn:/cygdrive/c/Program Files (x86)/Microsoft SQL Server/100/Tools/Binn:/cygdrive/c/Program Files/Microsoft SQL Server/100/Tools/Binn:/cygdrive/c/Program Files/Microsoft SQL Server/100/DTS/Binn:/cygdrive/c/Strawberry/perl/bin:/cygdrive/c/Program Files/Git/cmd:/cygdrive/c/apache-ant/apache-ant-1.10.5/bin:/cygdrive/c/openjdk/jdk-8/bin:/cygdrive/c/rust/bin:/cygdrive/c/Program Files/IcedTeaWeb/WebStart/bin:/cygdrive/c/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdk-tests/TKG/test_output_16049249488111/jdk_jdi_0/work/classes/com/sun/jdi
12:51:18  C:/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdkbinary/j2sdk-image/bin/java -agentlib:jdwp=transport=C:\\Users\\jenkins\\workspace\\Test_openjdk8_hs_sanity.openjdk_x86-32_windows\\openjdk-tests\\TKG\\test_output_16049249488111\\jdk_jdi_0\\work\\classes\\com\\sun\\jdi\\private_dt_socket,server=y,suspend=n -classpath "C:/Users/jenkins/workspace/Test_openjdk8_hs_sanity.openjdk_x86-32_windows/openjdk-tests/TKG/test_output_16049249488111/jdk_jdi_0/work/classes/com/sun/jdi" HelloWorld
12:51:18  FATAL ERROR in native method: JDWP One or more of the library paths supplied to jdwp, likely by sun.boot.library.path, is too long., jvmtiError=JVMTI_ERROR_INVALID_LOCATION(24)

Re-run Grinder: https://ci.adoptopenjdk.net/job/Grinder/4604/ Passed

lumpfish commented

ppc64_aix
Test_openjdk8_hs_sanity.openjdk_ppc64_aix #243 - All passed
Test_openjdk8_hs_sanity.system_ppc64_aix https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.system_ppc64_aix/60/ - 1 Failure already known intermittent: adoptium/aqa-systemtest#274
Test_openjdk8_hs_extended.system_ppc64_aix #60 - All passed
Test_openjdk8_hs_sanity.perf_ppc64_aix #52 - All passed

s390x_linux
Test_openjdk8_hs_extended.system_s390x_linux #356 - All passed
Test_openjdk8_hs_sanity.perf_s390x_linux https://ci.adoptopenjdk.net/job/Test_openjdk8_hs_sanity.perf_s390x_linux/50/ - Failed to execute java -version (test-marist-sles12-s390x-1)

15:13:47  Run /home/jenkins/workspace/Test_openjdk8_hs_sanity.perf_s390x_linux/openjdkbinary/j2sdk-image/bin/java -version
15:13:47  =JAVA VERSION OUTPUT BEGIN=
15:13:47  Error: dl failure on line 893
15:13:47  Error: failed /home/jenkins/workspace/Test_openjdk8_hs_sanity.perf_s390x_linux/openjdkbinary/j2sdk-image/jre/lib/s390x/server/libjvm.so, because libffi.so.6: cannot open shared object file: No such file or directory

Test_openjdk8_hs_sanity.system_s390x_linux #360 - All passed
Test_openjdk8_hs_sanity.openjdk_s390x_linux #362 - All passed

ppc64le_linux
Test_openjdk8_hs_extended.system_ppc64le_linux #373 - All passed
Test_openjdk8_hs_sanity.perf_ppc64le_linux #51 - All passed
Test_openjdk8_hs_sanity.system_ppc64le_linux #378 - All passed
Test_openjdk8_hs_sanity.openjdk_ppc64le_linux #378 - All passed

x86-64_mac
Test_openjdk8_hs_sanity.system_x86-64_mac #338 - All passed
Test_openjdk8_hs_extended.system_x86-64_mac #332 - All passed
Test_openjdk8_hs_sanity.openjdk_x86-64_mac #338 - All passed
Test_openjdk8_hs_sanity.perf_x86-64_mac #53 - All passed

lumpfish commented

s390x_linux will need to be rebuilt because the extended tests (which should not have been submitted against the release build) timed out the build job and the build was not archived.

sxa commented

Solaris:
Still won't build:

12:15:29  Undefined			first referenced
12:15:29   symbol  			    in file
12:15:29  Java_jdk_internal_platform_cgroupv1_Metrics_isUseContainerSupport

Arm:
Aarch64:
https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah does not have build jdk8u275-b01, is it not affected?

12:29:35  checkoutRequiredCodeToBuild:
12:29:35    workspace = /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-arm-hotspot/workspace/./build//src
12:29:35    BUILD_VARIANT = hotspot
12:29:35    TAG = jdk8u275-b01
12:29:35    BRANCH = dev
12:29:36  Checking out tag jdk8u275-b01
12:29:37  fatal: Couldn't find remote ref refs/tags/jdk8u275-b01
12:29:37  Failed cmd: git fetch origin "refs/tags/jdk8u275-b01:refs/tags/jdk8u275-b01"
12:29:37  WARNING: Cannot get tag due to previous failures. /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-arm-hotspot/workspace/target//metadata/scmref.txt will NOT be created!
12:29:37  checkoutRequiredCodeToBuild failed rc=128

Win:

ERROR: [WS-CLEANUP] Cannot delete workspace: Unable to delete 'E:\workspace\build-scripts\release\sign_build'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.
ERROR: Cannot delete workspace: Unable to delete 'E:\workspace\build-scripts\release\sign_build'. Tried 3 times (of a maximum of 3) waiting 0.1 sec between attempts.

Solaris will require a patch to be applied - it's in the main jdk8u codeline targetted for 8u282 but not backported yet. I'll look at getting that sorted today.

The Aarch64 will indeed need to be respun so expect an update to that repository at some point, but we can release the other platforms first

sxa commented

Failed to execute java -version (test-marist-sles12-s390x-1)

I've disabled that machine for now. It was recently activated but it looks like it doesn't have the full set of libraries available. I think we've seen this on SLES in the past. Now that it is deactivated it should not cause a problem but I will investigate further so we can reactivate after the releases are complete.

andrew-m-leonard commented

OpenJDK introduced a jdk-11.0.9.1 "patch" branch for this re-spin, whereby they "branched" the jdk-11.0.9+11 GA release to create the "patch" branch jdk-11.0.9.1. The re-spin build was then jdk-11.0.9.1+1.
For Adopt binaries and installers there are two areas that would not currently handle the "patch" number:

  • Binary metadata semver, which can only be format x.y.z+build => No field for patch
  • Windows MSI installer Product Version format a.b.c.revision => Revision currently "build" number, which would introduce incorrect ordering of 11.0.9.1

To resolve this we have updated both the semver and MSI ProductVersion to incorporate the "patch" number as a new branch of a given version, and allowing up to 100 (sub)builds for a given version, as follows:
OpenJDK version jdk-<major>.<minor>.<security>.<patch>+<build>

  • semver = major.minor.security+((patch*100)+build)
  • MSI product version = major.minor.security.((patch*100)+build)
    eg.jdk-11.0.9.1+1
    => semver = 11.0.9+101
    => MSI product version = 11.0.9.101
  • 👍1
sxa commented

To support these changes, we have the following PRs:

andrew-m-leonard commented

jdk8u275-b01 Win64:
sanity.functional:

  • cmdLineTester_loadLibraryTests_0:
21:10:03   [ERR] java.lang.UnsatisfiedLinkError: no abcdef in java.library.path
21:10:03   [ERR] 	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
21:10:03   [ERR] 	at java.lang.Runtime.loadLibrary0(Runtime.java:871)
21:10:03   [ERR] 	at java.lang.System.loadLibrary(System.java:1124)
21:10:03   [ERR] 	at org.openj9.test.loadLibrary.TestLoadLibrary.<clinit>(TestLoadLibrary.java:32)

Suspect this test does not work for Hotspot.

sanity.perf:

extended.perf:

andrew-m-leonard commented

jdk8u275-b01 zLinux:

sanity.external:

  • quarkus_quickstarts_test_0:

sanity.perf:

  • Aborted took too long..

extended.perf:

  • 10hr Timeout
lumpfish commented

jdk11 hotspot triage first pass. There are some tests which did not complete and need resubmitting. All failures seen are already known and non-stop ship on previous releases.

** aarch64_linux **

https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_aarch64_linux/369/ - All passed
sanity.perf - Tests were not submitted successfully
sanity.system - Tests were not submitted successfully
extended.system - Tests were not submitted successfully

** arm_linux **

https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_arm_linux/39/ - All passed
sanity.perf - Tests were not submitted successfully
sanity.system - Tests were not submitted successfully
extended.system - Tests were not submitted successfully

** ppc64_aix **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_ppc64_aix/42/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_ppc64_aix/48/console: Run incomplete due to adoptium/infrastructure#1676
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_ppc64_aix/263/console: Failed to run adoptium/infrastructure#1677
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_ppc64_aix/52/console: Already known issue with Math test failure (test case precision expectations incorrect): adoptium/aqa-tests#1893

** ppc64le_linux **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_ppc64le_linux/401/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_ppc64le_linux/402/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_ppc64le_linux/394/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_ppc64le_linux/394/ - All passed

** s390x_linux **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_s390x_linux/383/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_s390x_linux/377/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_s390x_linux/378/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_s390x_linux/378/ - All passed

** x86-32_windows **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_x86-32_windows/381/console - One already raised failure adoptium/aqa-tests#1773 (though that issue implies the test should have already been excluded?).
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_x86-32_windows/45/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_x86-32_windows/53/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_x86-32_windows/43/console - Already known issue with Math test failure (test case precision expectations incorrect): adoptium/aqa-tests#1893

** x86-64_linux **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_x86-64_linux/423/ - All passed
sanity.perf - Tests were not submitted successfully
sanity.system - Tests were not submitted successfully
extended.system - Tests were not submitted successfully

** x86-64_mac **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_x86-64_mac/405/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_x86-64_mac/407/console: Tests did not start - network issue error downloading prereqs
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_x86-64_mac/406/consoleFull: Test case failed to build due to adoptium/infrastructure#1673
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_x86-64_mac/399/ - All passed

** x86-64_windows **
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.openjdk_x86-64_windows/385/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.perf_x86-64_windows/337/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_sanity.system_x86-64_windows/379/ - All passed
https://ci.adoptopenjdk.net/job/Test_openjdk11_hs_extended.system_x86-64_windows/378/ - All passed

  • 👍1
andrew-m-leonard commented

jdk8u275-b01 (except for Solaris and ARM32/64) now published

lumpfish commented

jdk11 hotspot test resubmissions:

** aarch64_linux **

sanity.perf - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4633/ - All passed
sanity.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4634/ - All passed
extended.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4635/ - All passed

** arm_linux **

sanity.perf - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4636/ - All passed
sanity.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4637/ - All passed
extended.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4638/ - All passed

** ppc64_aix **

sanity.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4670/ - All passed
sanity.openjdk - https://ci.adoptopenjdk.net/view/Test_openjdk/job/Test_openjdk11_hs_sanity.openjdk_ppc64_aix/264/ - All passed

** x86-64_linux **

sanity.perf - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4639/ - All passed
sanity.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4640/ - JLM tests failed due to test machine failing to connect on localhost (adoptium/infrastructure#1627) - resubmitted again on different machine: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4644 - All passed
extended.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4641/ - All passed

** x86-64_mac **

sanity.perf - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4642/ - All passed
sanity.system - https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/4643/ - All passed

sxa commented

Patched solaris builds now running at https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1360/ from the jdk8u275-b01-solaris branch

  • 👍1
andrew-m-leonard commented

jdk8u275-b01_openj9-0.23.0 test triage:

pLinuxXL:

    java/net/MulticastSocket/SetGetNetworkInterfaceTest.java.SetGetNetworkInterfaceTest
    com/sun/jndi/ldap/LdapDnsProviderTest.java.LdapDnsProviderTest
    com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java.DeadSSLLdapTimeoutTest
    java/security/cert/PolicyNode/GetPolicyQualifiers.java.GetPolicyQualifiers
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java.TestAESWithProviderChange
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java.TestAESWithRemoveAddProvider

java/net/MulticastSocket/SetGetNetworkInterfaceTest.java.SetGetNetworkInterfaceTest seems additional to the normal failures, so re-submitted: https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.openjdk_ppc64le_linux_xl/6/

zLinuxXL:

renaissance-db-shootout_0:
  leveldbjni64-1.8 load failure

    com/sun/jndi/ldap/LdapDnsProviderTest.java.LdapDnsProviderTest
    com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java.DeadSSLLdapTimeoutTest
    java/security/cert/PolicyNode/GetPolicyQualifiers.java.GetPolicyQualifiers
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java.TestAESWithProviderChange
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java.TestAESWithRemoveAddProvider

Win64, Win64_xl and Win32 builds all failed:
Re-submitting: https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1365/

Mac and MacXL all test jobs failed:
Re-submitted: https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1366/
=> All sanity & special test suites Passed

zLinux:

extended.perf : https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.perf_s390x_linux/2/consoleFull

  • renaissance-db-shootout_0
leveldbjni64-1.8 library load problem

extended.openjdk : https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.openjdk_s390x_linux/5/#showFailuresLink

    com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java.DeadSSLLdapTimeoutTest
    com/sun/jndi/ldap/LdapDnsProviderTest.java.LdapDnsProviderTest
    java/security/cert/PolicyNode/GetPolicyQualifiers.java.GetPolicyQualifiers
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java.TestAESWithProviderChange
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java.TestAESWithRemoveAddProvider

xLinux:

  • sanity.openjdk : java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java.ProducerConsumerLoops
Timeout...

Re-run: https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_sanity.openjdk_x86-64_linux/391/ Passed

AIX:
extended.functional : https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.functional_ppc64_aix/11/

09:12:17  FAILED test targets:
09:12:17  	testDDRExt_General_0
09:12:17  	testDDRExt_Callsites_0
09:12:17  	testDDRExt_JITExt_0
09:12:17  	testDDRExt_SharedClasses_0
09:12:17  	testDDRExtJunit_CollisionResilientHashtable_0
09:12:17  	testDDRExtJunit_StackMap_0
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock1_1
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock2_1
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock3_1
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock4_1
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock5_1
09:12:17  	testDDRExtJunit_MonitorsAndDeadlock6_1
09:12:17  	testDDRExtJunit_FindExtThread_0
09:12:17  	TestAttachErrorHandling_SE80_0
09:12:17  	gcNotificationTest_Metronome_0
09:12:17  	gcNotificationTest_Metronome_1
09:12:17  	threadMXBeanTestSuite1_2
09:12:17  	threadMXBeanTestSuite1_6
09:12:17  	threadMXBeanTestSuite2_2
09:12:17  	threadMXBeanTimedParkTest_2
09:12:17  	threadMXBeanTimersTest_2
09:12:17  	jniOnLoadExceptions_3
09:12:17  	testvmcheck_3
09:12:17  	ThreadRegressionTests_3
09:12:17  	cmdLineTester_classesdbgddrext_1
09:12:17  	cmdLineTester_classesdbgddrext_aix_1
09:12:17  	cmdLineTester_decompilationTests_nongold_2
09:12:17  	cmdLineTester_shrcdbgddrext_1
09:12:17  	cmdLineTester_verbosetest_5

Seems to be the usual failures...

extended.openjdk :
60 failures... seems more than normal, re-submitting: https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.openjdk_ppc64_aix/9/

pLinux:
special.functional : failed=>https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_special.functional_ppc64le_linux/18/
Re-submitted: https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_special.functional_ppc64le_linux/20/ Passed

extended.openjdk : https://ci.adoptopenjdk.net/job/Test_openjdk8_j9_extended.openjdk_ppc64le_linux/6/#showFailuresLink

    com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java.DeadSSLLdapTimeoutTest
    java/security/cert/PolicyNode/GetPolicyQualifiers.java.GetPolicyQualifiers
    com/sun/jndi/ldap/LdapTimeoutTest.java.LdapTimeoutTest
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithProviderChange.java.TestAESWithProviderChange
    com/sun/crypto/provider/Cipher/AES/TestAESCiphers/TestAESWithRemoveAddProvider.java.TestAESWithRemoveAddProvider

Usual failures

lumpfish commented

jdk11 hotspot tests now complete - comments #185 (comment) and #185 (comment) above updated.
Summary - no test failures which have not previously been raised against earlier releases.
So jdk11 hotspot looks good to release.

  • 👍2
gdams commented

@lumpfish +1 to releasing jdk11 hotspot

sxa commented

Permission requested to ship on Solaris (x64 and SPARC) based on the branch with the build fix backport as per 8u272-b01:

NOTE: Filenames have _solaris in them due to the alternate tag we build from to include the patch. 8u272-b01 was released with that in the name too
@AdoptOpenJDK/tsc Please 👍 this comment to approve

  • 👍1
sxa commented

Linux/aarch32 (armv7l for raspberry pi etc.) has failing jdk_util_0 and jdk_jdi_0 which seems consistent with the analysis for 8u272-b01.

@smlambert Looking for approval primarily from you for this one - wasn't clear if there was an issue already out on the current arm32 sanity.openjdk failures I could compare these results with but hopefully you can confirm if these are acceptable to ship with

[EDIT: jdk_jdi passed here, util except TabulatorsTest passed in 4698 and util except MapOpTest and SliceOpTest seemed to passed in 4696

smlambert commented

re: #185 (comment) arm32 failures, jdk_jdi are 'dt_socket failed to initialize' which I am fairly certain is related to machine config (failing on build-scaleway-ubuntu1604-armv7-2 but passing on test-aahlenst-armv7-raspbian-pi4-1). 👍 to ship with the handful of intermittent failures (now that we finally running regular testing, we can/will investigate root cause of remainder).

  • ❤️1
andrew-m-leonard commented

jdk8u275-b01_openj9-0.23.0:

* Aarch64(EA) : https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1357/

* Mac : https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1366/

* Win : https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1370/

* All others : https://ci.adoptopenjdk.net/job/build-scripts/job/openjdk8-pipeline/1356/

jdk8u275-b01_openj9-0.23.0 all sanity test suites Passed, good for publish
@sxa @smlambert

  • 👍1
smlambert commented

Nice to see an 'all passed' :)
+1 to publish jdk8u275-b01_openj9-0.23.0

sxa commented

Released the remaining HotSpot builds under:

Point of note: The arm32 version string currenetly does not contain AdoptOpenJDK although this is NOT a regression. Raised in adoptium/temurin-build#2229

sxa commented

Support table update: AdoptOpenJDK/openjdk-website#845

douph1 commented

Sorry, I'm little late here : )

To resolve this we have updated both the semver and MSI ProductVersion to incorporate the "patch" number as a new branch of a given version, and allowing up to 100 (sub)builds for a given version, as follows:

Nothing here prevent us to not do the math for patch number greater than 100 and potentially generate a conflicting version number

https://github.com/AdoptOpenJDK/openjdk-build/blob/master/pipelines/library/src/common/VersionInfo.groovy#L275-L277

Hypothetical version number
16.0.1.0+102 -> 16.0.1.102
16.0.1.1+1 -> 16.0.1.101 (but this one is newer than the first .. )

I have looked at old build number never found greater than 37 if I remember well.
So I thinking we are lucky but with adopt api I have found build "181" !
{
"build": 181,
"major": 9,
"minor": 0,
"openjdk_version": "9+181",
"security": 0,
"semver": "9.0.0+181"
}

Must we open a new issue to hadle build n° >=100 and do *1000 ?

andrew-m-leonard commented

Sorry, I'm little late here : )

To resolve this we have updated both the semver and MSI ProductVersion to incorporate the "patch" number as a new branch of a given version, and allowing up to 100 (sub)builds for a given version, as follows:

Nothing here prevent us to not do the math for patch number greater than 100 and potentially generate a conflicting version number

https://github.com/AdoptOpenJDK/openjdk-build/blob/master/pipelines/library/src/common/VersionInfo.groovy#L275-L277

Hypothetical version number
16.0.1.0+102 -> 16.0.1.102
16.0.1.1+1 -> 16.0.1.101 (but this one is newer than the first .. )

I have looked at old build number never found greater than 37 if I remember well.
So I thinking we are lucky but with adopt api I have found build "181" !
{
"build": 181,
"major": 9,
"minor": 0,
"openjdk_version": "9+181",
"security": 0,
"semver": "9.0.0+181"
}

Must we open a new issue to hadle build n° >=100 and do *1000 ?

I would definitely say 100 is enough, the jdk9 build 181 was when Java used to do GA releases every 1-2 years, so jdk7/8/9 build numbers kept incrementing 1 every week etc.. for a year or two... This is obviously obsolete now. The only releases that have significant number of builds are new versions, so currently jdk-16 will keep incrementing every week or so until about February. New releases have a run-up of about 9 months, so even if a new build happened every week we still would not reach more than about 40.

douph1 commented

Fine. I didn't know the build number was the week of release since the GA ..

sxa commented

I believe we are now complete since the API is showing the new 11.0.9.1+1 version AdoptOpenJDK/openjdk-api-v3#313 (comment) AdoptOpenJDK/openjdk-api-v3#315 AdoptOpenJDK/openjdk-api-v3#317 API link. Comments to be usd as inpiut to the retrospective can be added into the one for the October release #181