-
Notifications
You must be signed in to change notification settings - Fork 721
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 javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java - SSLException: Input record too big / Tag mismatch! #15862
Comments
Try a grinder (100x) on 0.33.1 - passed
Another Grinder (200x) on 0.35 with In the last two grinders there was also a different failure on the same test (rhel7s390x-4-3, rhel7s390x-4-5, rhel7s390x-4-8, rhel9s390xrt-1).
|
Subset of OpenJDK changes (e361c66..d0e3108):
grinder (200x) on xlinux 0.35 - passed |
@joransiu this seems like a JIT issue introduced since the last release. |
@r30shah has kindly offered to look into this. |
I was able to get the same failure on xlinux, so this is not zlinux specific. |
Thanks a lot @pshipton for checking if the issue is Z specific or not. While I am checking what causes the failure (I tried running this manually on Ubuntu - 20.04, but can not reproduce in 5 runs), do you still suspect it is JIT related issue or any OpenJDK change listed in #15862 (comment) could have caused it? |
I'm not familiar with the OpenJDK code to know if one of the changes could be causing this. Maybe @alon-sh would be able to make an assessment. It feels like a JIT issue, but I could be wrong. I'm still running grinders, so far I haven't been able to reproduce outside of OpenJ9 0.35. The "same" OpenJDK code is used for Temurin, and I haven't reproduced it there yet. |
Grinders are finished (enough), no new failures on Temurin or 0.33. I'm done running grinders unless there is a suggestion for other options to try. |
I was able to extract out the test to run easily through Java command line. Uploading the test here for reference. Looking at the unit test code, I do not see anything specific that stands out. Exception is thrown at [1] where the packet size exceeds the max buffer size fixed for SSLRecord. I am able to get it reproduced with JIT disabled as well.
As @pshipton noted in last comment, it does not fail with Temurin or 0.33, it might be OpenJ9 specific. Checking is it passes with 0.33 with the unit test. |
I would say try -Djdk.nativeCrypto=false but that was already tried and still fails so its not the OpenSSL code. At this point I don't have any further to add except to say that the TLS engine for both OpenJ9 and Temurin is identical. |
Both failures reproduce with -Xint -Xshareclasses:none -Xgcpolicy:optthruput or gencon. I haven't been able to reproduce it with 0.33.1 I've created new JVMs as follows. Preliminary results indicate something changed in the openjdk code to cause these problems with OpenJ9.
I'll continue looking for suspect OpenJDK changes to try and isolate which change is causing the failures. |
ibmruntimes/openj9-openjdk-jdk8@ca82562...fec4a25
Trying builds without these changes. |
|
I created another build where the only change is reverting the change to sun/security/ssl/SSLContextImpl.java from 8245263: Enable TLSv1.3 by default on JDK 8u for Client roles (i.e. ibmruntimes/openj9-openjdk-jdk8@cc2781c5a50) and this seems to fix the problem. Not sure what's wrong with our TLSv1.3 support. I wonder if something we changed to support OpenSSL could have broken it? Backing out the FIPS changes didn't fix it, so those changes are not the issue. I'll see if I can back out OpenSSL support changes to resolve the problem. Otherwise I'm not sure where to go from here. @alon-sh in case you have any ideas. |
I can duplicate "Input record too big" and "Tag mismatch!" failures on xlinux Temurin. This is not an OpenJ9 issue.
|
Failure link
From an internal build(
ubu22s390x-rt1-1
):Rerun in Grinder - Change TARGET to run only the failed test targets.
Optional info
Failure output (captured from console output)
50x internal grinder - failed 7 / 150, failing machines: ubu22s390x-rt5-1, rhel7s390x-4-1
The text was updated successfully, but these errors were encountered: