JDK-8220198 : Lots of com/sun/crypto/provider/Cipher tests fail on x86_32 due to missing SHA512 stubs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-05
  • Updated: 2019-09-26
  • Resolved: 2019-03-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13
11.0.4Fixed 12.0.2Fixed 13 b14Fixed
Related Reports
Relates :  
Relates :  
Description
Lots of tests fail on x86_32 tier1. Notably, this bunch:

$ CONF=linux-x86-server-fastdebug make run-test TEST=com/sun/crypto/provider/Cipher/ TEST_VM_OPTS="-XX:+UseParallelGC -XX:-TieredCompilation"
...
Test results: passed: 78; error: 11

This passes:
$ CONF=linux-x86-server-fastdebug make run-test TEST=com/sun/crypto/provider/Cipher/ TEST_VM_OPTS="-XX:+UseParallelGC -XX:-TieredCompilation -XX:-UseSHA512Intrinsics"
...
Test results: passed: 89

hs_err is foobared as well, with no stack trace information:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000000, pid=108017, tid=108339
#
# JRE version: OpenJDK Runtime Environment (13.0) (fastdebug build 13-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK Server VM (fastdebug 13-internal+0-adhoc.shade.jdk-jdk, mixed mode, parallel gc, linux-x86)
# Problematic frame:
# 
[error occurred during error reporting (printing problematic frame), id 0xe0000000, Internal Error (/home/shade/jdk-jdk/src/hotspot/cpu/x86/frame_x86.inline.hpp:49)]

# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#


It does not happen in 8u. It does happen in 11u. I heavily suspect JDK-8165381 is the root cause.
Comments
Fix Request (12u, 11u) Backporting this fix makes x86_32 more reliable. It is not critical for 11.0.3, because VM crashes somewhat "cleanly" and there is a clear workaround. The patch applies to 11u and 12u without problems. The test suite mentioned in description fails without the patch and passes with the patch. x86_64 passes tier1 in both 11u and 12u with the patch. The risk is low.
01-04-2019

This makes tests pass: diff -r 5ee30b6991a7 src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp Mon Dec 03 16:25:27 2018 +0100 +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp Tue Mar 26 13:16:24 2019 +0100 @@ -902,9 +902,11 @@ } if (UseSHA && supports_avx2() && supports_bmi2()) { +#ifdef _LP64 if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { FLAG_SET_DEFAULT(UseSHA512Intrinsics, true); } +#endif } else if (UseSHA512Intrinsics) { warning("Intrinsics for SHA-384 and SHA-512 crypto hash functions not available on this CPU."); FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); diff -r 5ee30b6991a7 src/hotspot/share/opto/graphKit.cpp --- a/src/hotspot/share/opto/graphKit.cpp Mon Dec 03 16:25:27 2018 +0100 +++ b/src/hotspot/share/opto/graphKit.cpp Tue Mar 26 13:16:24 2019 +0100 @@ -2450,6 +2450,8 @@ Node* parm2, Node* parm3, Node* parm4, Node* parm5, Node* parm6, Node* parm7) { + assert(call_addr != NULL, "sanity"); + // Slow-path call bool is_leaf = !(flags & RC_NO_LEAF); bool has_io = (!is_leaf && !(flags & RC_NO_IO));
26-03-2019

So, only x86_64 code initializes these in stubGenerator_x86_64.cpp: if (UseSHA512Intrinsics) { StubRoutines::x86::_k512_W_addr = (address)StubRoutines::x86::_k512_W; StubRoutines::x86::_pshuffle_byte_flip_mask_addr_sha512 = generate_pshuffle_byte_flip_mask_sha512(); StubRoutines::_sha512_implCompress = generate_sha512_implCompress(false, "sha512_implCompress"); StubRoutines::_sha512_implCompressMB = generate_sha512_implCompress(true, "sha512_implCompressMB"); }
26-03-2019

SEGV at PC=0 probably means the generated stub is not really generated. This new assert would fail instead of crashing the with that SEGV: diff -r 5ee30b6991a7 src/hotspot/share/opto/graphKit.cpp --- a/src/hotspot/share/opto/graphKit.cpp Mon Dec 03 16:25:27 2018 +0100 +++ b/src/hotspot/share/opto/graphKit.cpp Tue Mar 26 13:08:36 2019 +0100 @@ -2443,20 +2443,22 @@ Node* GraphKit::make_runtime_call(int flags, const TypeFunc* call_type, address call_addr, const char* call_name, const TypePtr* adr_type, // The following parms are all optional. // The first NULL ends the list. Node* parm0, Node* parm1, Node* parm2, Node* parm3, Node* parm4, Node* parm5, Node* parm6, Node* parm7) { + assert(call_addr != NULL, "sanity"); + // Slow-path call bool is_leaf = !(flags & RC_NO_LEAF); bool has_io = (!is_leaf && !(flags & RC_NO_IO)); if (call_name == NULL) { assert(!is_leaf, "must supply name for leaf"); call_name = OptoRuntime::stub_name(call_addr); } CallNode* call; if (!is_leaf) { call = new CallStaticJavaNode(call_type, call_addr, call_name, At: Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xaf3858] GraphKit::make_runtime_call(int, TypeFunc const*, unsigned char*, char const*, TypePtr const*, Node*, Node*, Node*, Node*, Node*, Node*, Node*, Node*)+0x6f8 V [libjvm.so+0xe5894f] LibraryCallKit::inline_sha_implCompress(vmIntrinsics::ID)+0x1cf V [libjvm.so+0xe68203] LibraryIntrinsic::generate(JVMState*)+0x1b3 V [libjvm.so+0x98f3be] Parse::do_call()+0x48e V [libjvm.so+0x1114db4] Parse::do_one_bytecode()+0x2024 V [libjvm.so+0x1104f24] Parse::do_one_block()+0x434 V [libjvm.so+0x1105637] Parse::do_all_blocks()+0x237 V [libjvm.so+0x11071d9] Parse::Parse(JVMState*, ciMethod*, float)+0xb49
26-03-2019