JDK-8235385 : Crash on aarch64 JDK due to long offset
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: openjdk8u292,11,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2019-12-05
  • Updated: 2022-06-21
  • Resolved: 2020-01-09
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 15 Other
11.0.16Fixed 15 b06Fixed openjdk8u352Fixed
Related Reports
Relates :  
JDK-8288865 - [aarch64] LDR instructions must use legitimized addresses
Relates :  
JDK-8287508 - The tests added to jdk-8 by 8235385 are to be ported to jdk-11
Relates :  
JDK-8262894 - [macos_aarch64] SIGBUS in Assembler::ld_st2
Description
Found a crash on aarch64. 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (assembler_aarch64.hpp:251), pid=125009, tid=125020
#  guarantee(chk == -1 || chk == 0) failed: Field too big for insn
#
# JRE version: OpenJDK Runtime Environment (13.0.1) (build 13.0.1-testing+0-builds.shipilev.net-openjdk-jdk13-b44-20191127)
# Java VM: OpenJDK 64-Bit Server VM (13.0.1-testing+0-builds.shipilev.net-openjdk-jdk13-b44-20191127, mixed mode, tiered, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x2a5b8c]  Instruction_aarch64::sf(long, int, int)+0x64
#
# 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
---------------  T H R E A D  ---------------

Current thread (0x0000ffff80607800):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=125020, stack(0x0000ffff05fd8000,0x0000ffff061d8000)]


Current CompileTask:
C2:    132  113       4       MyTest::toBytes (464 bytes)

Stack: [0x0000ffff05fd8000,0x0000ffff061d8000],  sp=0x0000ffff061d36d0,  free space=2029k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x2a5b8c]  Instruction_aarch64::sf(long, int, int)+0x64
V  [libjvm.so+0x2a7ab0]  Assembler::ld_st2(RegisterImpl*, Address const&, int, int, int)+0x3e8
V  [libjvm.so+0x254a8c]  loadStore(MacroAssembler, void (MacroAssembler::*)(RegisterImpl*, Address const&), RegisterImpl*, int, RegisterImpl*, int, int, int) [clone .constprop.115]+0xdc
V  [libjvm.so+0x25cb48]  storeINode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x138
V  [libjvm.so+0x4c3c7c]  Compile::scratch_emit_size(Node const*)+0x244
V  [libjvm.so+0xa6cea4]  Compile::shorten_branches(unsigned int*, Compile::BufferSizingData&)+0x22c
V  [libjvm.so+0xa74f88]  Compile::Output()+0x778
V  [libjvm.so+0x4ccd6c]  Compile::Code_Gen()+0x40c
V  [libjvm.so+0x4cff38]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xc28
V  [libjvm.so+0x405f10]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x168
V  [libjvm.so+0x4d8558]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2f8
V  [libjvm.so+0x4d97c8]  CompileBroker::compiler_thread_loop()+0x3d0
V  [libjvm.so+0xcede08]  JavaThread::thread_main_inner()+0xb8
V  [libjvm.so+0xcf3d18]  Thread::call_run()+0x108
V  [libjvm.so+0xa5d560]  thread_native_entry(Thread*)+0xf8
C  [libpthread.so.0+0x7bb0]  start_thread+0xb4
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1122 Date: 2022-06-01 07:21:28 +0000
14-06-2022
Fix Request (8u-dev) The following changes were done to the patch to 11u-dev - the overload of loadStore() updated to be conform with the baseline - resolved baseline conflicts in copyright sections - the reproducer was adopted to JTReg and put under Git Verified (18.04.6 LTS / aarch64) with attached reproducers, 10 of 10 runs passed for both. Aproximately a half of runs crashed before I've applied the patch. Regression (18.04.6 LTS / aarch64): compiler & runtime
05-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk8u-dev/pull/30 Date: 2022-04-04 06:14:30 +0000
04-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk8u-dev/pull/31 Date: 2022-04-04 06:24:28 +0000
04-04-2022
Fix Request (11u-dev) The changes are a composition of the fix released by Andrew to 15 and Wang's patch. It applies legitimizing overload of loadStore() from 15 to very few functions. Additional changes: - out-of-date ad_encode.m4 was actualized Verified (18.04.6 LTS / aarch64) with attached reproducers, 10 of 10 runs passed for both. Aproximately a half of runs crashed before I've applied the patch. Regression (18.04.6 LTS / aarch64): hotspot_compiler
31-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/960 Date: 2022-03-29 14:50:55 +0000
29-03-2022
Please try it and see. If it looks right, post it for review and I'll have a look. It might be a good idea to back-port legitimize_address() and call it from the aarch64 patterns rather than using a separate add(); load/store as Wang Zhuo's patch does. That would localize the impact of the change to just those few AD patterns.
26-03-2022
Got it, thanks a lot. And should I backport Wang's patch to 11u-dev or it's better to apply it locally?
26-03-2022
This is an invasive and high-risk patch to backport. We've fixed rare crashes like this before, and ended up breaking HotSpot in bigger ways. There almost certainly is a more targeted way to fix this specific problem than backporting the entire patch.. Wang Zhuo's attached patch looks like a good starting point.
26-03-2022
I'm going to backport the patch to jdk11u-dev because we've got a customer bug referring to this issue. Any comments, updates, or objections?
25-03-2022
[~aph] I've noticed that this affects JDK 11u. Do you plan to backport?
17-12-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/ec872b4817f8 User: aph Date: 2020-01-09 14:41:11 +0000
09-01-2020
This crash was observed on JDK13/JDK11/JDK8. Currently I am using this patch to fix this issue http://cr.openjdk.java.net/~wzhuo/BigOffsetAarch64/webrev.00/jdk13u.patch Please review.
05-12-2019
This crash was found on an online applications. I wrote a test to reproduce it more easily. Please check attached MyTest.java, you may need rerun some times to trigger the crash.
05-12-2019