-
Notifications
You must be signed in to change notification settings - Fork 737
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
testJITServerArguments_0 failure on ppc64le: crash during initial SSL connection #19325
Comments
Attn @mpirvu. |
JDK8 ppc64le_linux(
|
The following tests failed 10/10 on cent8le-svl-rt5-1 and rhel8le-rtp-rt1-1. Passed on sles12le-rtp-rt7-1, ubu20le-rtp-rt12-1, ubu20le-svl-rt1-1. |
@cjjdespres is looking into this failure. |
I haven't been able to reproduce this locally yet, unfortunately, but from what I've seen it only seems to fail on rhel8 and cent8. Could this be related to https://github.ibm.com/runtimes/infrastructure/issues/9147#issuecomment-76212158? It seems as though the server is crashing in this call: openj9/runtime/compiler/runtime/Listener.cpp Line 106 in b1c3564
judging from the logs, anyway - the client fails to complete the SSL handshake here: openj9/runtime/compiler/net/ClientStream.cpp Line 259 in b1c3564
probably because of the server crash. |
To reproduce, generate a cert/key pair with
Then run The |
Actually, I don't think I tested building OpenSSL 3.0.7 from source on RHEL 8.8, so maybe that would work as well. |
@ymanton Is that instruction |
I grepped through the |
It's only supported on POWER 9 and later. The machine getting I don't think you'd see this if you built OpenSSL from source on the target machine or installed a package available from the repos the machine has access to. Did you get your EPEL package from epel-8 or epel-9? RHEL 9 dropped support for P8 so all packages for RHEL 9 are going to be built for P9 as the baseline. |
I got it from epel-8. |
I'm fairly sure it's epel-8, anyway. This is on RHEL 8.8. The exact package is |
Do you see the exact same crash outside of a debugger? From what I can tell of the openssl code, it expects That code will check the auxvector1 if it was built with that support, otherwise fall back to testing with
The only discrepancy is that I don't see any of the functions in that code in your backtrace, and since you appear to have debug symbols available they wouldn't be hidden by inlining for example. Your backtrace looks like an operation is actually in progress. It could a bug, but I would think this stuff would have been thoroughly tested. If you run it in gdb it will catch Footnotes |
Actually don't bother with all that work, your problem looks like exactly this bug: openssl/openssl#19163 |
If I understand correctly, openssl 3.0.7 on Power has a bug which prevents us from running JITServer with encryption on Power 8 machines. |
The openssl 3.0.7 package that was recently installed on the rhel8/cent8 power test machines, at least. |
Yes, it looks like it was fixed upstream in 3.3 and backported to 3.1, but I'm not sure why 3.0 didn't get it. |
Just to record it here - the problem seems to be that the epel-8 OpenSSL package (version 3.0.7) was patched to include some performance improvements for power 9 and up introduced into OpenSSL 3.1 and later versions, but was not patched to include a later bug fix that prevents this issue from occurring. @ymanton mentioned that he would raise an issue with Red Hat to try to resolve the problem. |
It looks like there is a @cjjdespres you can download it here and test it on a VM if you're inclined. |
JDK21 ppc64le_linux(
|
There have been failures in
You can see that it's crashing in |
|
These failures seem to have disappeared from the nightly builds, so it looks like @mpirvu was right about this being fixed. (I can't quite remember what the resolution was in the end, though). I think this can be closed for now. |
First reported here. The server appears to crash during initial SSL connection in the subtests "Test SSL condition" and "Test SSL Failure Case with mismatched certificate". Console log:
The rest of the log seems to be the remainder of the (otherwise successful) client run. I think the SSL error message
unexpected eof while reading:ssl/record/rec_layer_s3.c:321
in the logs was emitted by the client after the SSL connection failed.Seen in, e.g., the internal tests:
I ran a 50x grinder here and got one iteration with 10/10 failed tests. The other 4 iterations passed.
The text was updated successfully, but these errors were encountered: