-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jdk_security3_0_FAILED IOException: NSS initialization failed #17137
Comments
This seems like a machine problem. |
Does the tests failed in FIPS mode or not? If the failures are not in FIPS mode, then maybe an environment issue, rerun the tests to see if the issues are still there. If they failed in FIPS mode, from above, there are two failed test cases: TEST: sun/security/pkcs11/Provider/Login.java
TEST: sun/security/pkcs11/Secmod/AddPrivateKey.java
And both of them start fail at
From the PKCS11Test.java around line 142 and 150, codes below:
They are trying to initialize the SunPKCS11 provider using the specified config file. Take test "AddPrivateKey.java" as example, at line "AddPrivateKey.main(AddPrivateKey.java:76)", codes below:
It is trying to use the config file " BASE + SEP + "nss.cfg"" which is a file in the test folder, to initialize the SunPKCS11 in the NSS security mode.
But, the SunPKCS11 can only be initialized once, and in our case, the SunPKCS11 is already initialized in NSS as FIPS mode, so it can not be initialize again by other NSS config files. |
@taoliult pls see my comments below
The failed JVM is JDK17
50x internal grinder passed in 3 machines, failed at rhel9lert-1, with another infra error.
Since this is non-FIPS mode run, can the |
@JasonFengJ9 Sorry for replying late. Right now, Semeru FIPS only support the Redhat linux x86 platform, it doesn't support the ppc64le. You mentioned, launched another grinder at the same machine and all failed. Does this machine infrastructure/OS is same as the other 3 machines which you mentioned passed? As I remember when I look at the SunPKCS11 provider, before initializing the nss secmod, it will check if the nss secmod is already initialized or not, if it already initialized, then it won't be initialized again. But in your failed case rhel9lert-1, I see it failed at:
It failed after check the "already initialized", which return false. That mean, the nss secmod is not initialized yet. So, next, it will try to initialize the nss secmod, but failed when initializing. So, the failures is not due to initialize twice. So, does the failed machine same as the other 3 passed machines? If there are same, then it should be a kind of machine issue. If there are not same, maybe, you can first try to run the same tests using another machine same as the failed one, to check if it is due to the machine issue or not. |
JDK20 s390x_linux failed at a different machine
|
Guessing this is a machine setup issue. |
JDK11 x86-64_linux rc1(
|
JDK17 x86-64_linux(
|
JDK21 s390x_linux(
50x grinder - passed in 6 machines, failed in the other 4 machines. |
I'd bet this is a machine setup issue. |
Failure link
From an internal build(
rhel9lert-2
):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x internal grinder - passed in 3 machines, failed at rhel9lert-1, another infra error
The text was updated successfully, but these errors were encountered: