Solaris x64 and sparc: TrustAnchor.java cannot find NSS module

[adamfarley]

• test suite/name: sun/security/pkcs11/Secmod/TrustAnchors.java
• a link into recent Test_ job on https://ci.adoptium.net which showed the failure: https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-x64-temurin-simpletest/108/artifact/output_17527215147474/jdk_security3_0/work/sun/security/pkcs11/Secmod/TrustAnchors.jtr/*view*/
• Hyperlink to re-run in Grinder: Unknown. Does Solaris still permit grinders via the usual job?
• Is there an existing issue elsewhere covering this? Not that I can find. First mentioned here and here.
• Which machine(s) does it work on? - None.
• Which machine(s) does it fail on? - The only one we have

Any other details:

----------System.out:(1/46)----------
libsoftokn3 version = 3.12100.  ECC Extended.
----------System.err:(22/1319)----------
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at PKCS11Test.getSunPKCS11(PKCS11Test.java:108)
	at TrustAnchors.main(TrustAnchors.java:58)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.lang.Thread.run(Thread.java:750)
Caused by: java.security.ProviderException: NSS module not available: trustanchors
	at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:272)
	at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
	... 12 more

This forum comment suggests that perhaps the contents of java.library.path or LD_LIBRARY_PATH could be causing this bug.

Please check the contents of "/usr/jdk/packages/lib/amd64" and see if anything changed around the same time as this started happening?

Job history says the parent target (jdk_security3_0) didn't see this issue on the 27th of May, but did see it on the 29th.

[sxa]

Nothing will have changed on that machine. The environment could be different though, although that would also have been the case for the April release.

Noting that it was not mentioned in adoptium/aqa-tests#6200 (comment) - the equivalent log from that run appears looks to have been https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-solaris-sparcv9-temurin-simpletest/78/artifact/output_17448429182862/jdk_security3_0/work/sun/security/pkcs11/Secmod/TrustAnchors.jtr/*view*/

[sxa]

I'll look at reproducing directly on the machine tomorrow and seeing if I can get this through. In answer to your other question, it's not possible to run Grinders as the limitation is that Jenkins now requires JDK17 for the agent processes on each machine, and there is no JDK17 build for Solaris 10.