`jdk_security3_0` and `jdk_security1_0` have problems on Windows systems.

Open sxa opened this issue 11 months ago • 6 comments

Please set the title to indicate the test name and machine name where known.

To make it easy for the infrastructure team to repeat and diagnose, please answer the following questions:

test suite/name (e.g, BUILD_LIST, TARGET, CUSTOM_TARGET)? jdk_security3_0 and jdk_security1_0
a link into recent Test_ job on https://ci.adoptium.net which showed the failure: https://ci.adoptium.net/job/Test_openjdk21_hs_sanity.openjdk_x86-64_windows/211/tapTestReport/ or https://ci.adoptium.net/job/Grinder/12170/testReport/
Hyperlink to re-run in Grinder: jdk_security3_0 on test-4
Is there an existing issue elsewhere covering this?
Which machine(s) does it work on? test-azure-win2022-x64-1 doesn't seem to have the math failures
Which machine(s) does it fail on? test-azure-win20220-x64-4

Any other details: This is a full dump of links etc. so may have more information not directly relevant to this, especially since some of it covers the wsl issue covered in another issue in this repostitory: : Noticed during some experimentation I've been doing on Windows. I initially thought that this was restricted to the new -4 machine (which is currently offline) but it has also been seen on -1:

Original failures on -1 in jdk_security1 and jdk_security4 (Some covered by https://github.com/adoptium/infrastructure/issues/3853)

- sun/security/krb5/runNameEquals.sh.runNameEquals java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh.ClassLoaderDeadlock 94 ms 1

jdk_security3 and jdk_imageio failed in two tests on -1 (checked after seeing jdk_security3 failures on -4) :

- sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantec javax/imageio/plugins/jpeg/JPEGsNotAcceleratedTest.java.JPEGsNotAcceleratedTest 2.8 sec 1

For the above, the first failure is sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target and the second is java.awt.HeadlessException: The application does not have desktop access, but this program performed an operation which requires it. which should have been fixed by running the agent via a terminal on the logged in machine instead of as a service but doesn't seem to have been fully resolved for some reason...

The full list of jdk_security3 failures on -4 were as follows (The math ones seem to be Agent error: java.lang.Exception: Agent 38 timed out with a timeout of 960 seconds; check console log for any additional details:

- sun/security/ssl/X509TrustManagerImpl/distrust/Symantec.java.Symantec javax/net/ssl/SSLSocket/Tls13PacketSize.java.Tls13PacketSize 2.7 sec 1

Jan 06 '25 11:01 sxa