JDK-8182581 : aarch64: fix for crash caused by earlyret of compiled method
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2017-06-20
  • Updated: 2021-02-01
  • Resolved: 2017-06-20
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 10 JDK 9 Other
10 b14Fixed 9Fixed openjdk8u292Fixed
Related Reports
Relates :  
Description
Reported by snazarkin at azul.com:

Hi!

    Please review the fix [1] for the crash happens when compiled method is forced to return early.  We found this issue when running vm/jvmti/ForceEarlyReturnObject/fero001/fero00103/fero00103.html JCK test on CPU with 47 cores. 

    The crash happens at the time when test  code tries to check returned value and gets invalid oop.  Despite correct object was acquired by load_earlyret_value(), it is  accidentally substituted on the stack when remove_activation() is executed (see TemplateInterpreterGenerator::generate_earlyret_entry_for). Substitution, in turns, happens due to overlapping of expression and native stacks. Particularly esp equals to sp because frame with no expression is restored (that is correct).  

    After that execution of following code sequence replaces TOS with  some irrelevant value. 

push(tos)  // -> puts value on expression stack
unlock_object() // -> calls call_VM() and save registers on native stack, in fact, at the same place as esp
pop(tos) // -> restores  invalid value

The fix restores expression stack to max possible for deoptimized method size.  Please consider if this fix covers the case workarounded by  [2] (I was not able to trace back and find the reason for this changeset). 

[1] http://cr.openjdk.java.net/~snazarki/earlyret_crash/
[2] http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/file/83f5fdfd56ec/src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp#l1909

Sergey Nazarkin



Reproduced hs error messages:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000007f783acc1c, pid=20121, tid=0x0000007f8753b200
#
# JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-yangfei_2017_06_20_10_03-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-aarch64 compressed oops)
# Problematic frame:
# J 10 C1 java.lang.String.equals(Ljava/lang/Object;)Z (81 bytes) @ 0x0000007f783acc1c [0x0000007f783acb40+0xdc]
#
# Core dump written. Default location: /home/guoge/JVM/test/testsuite/jck8/JCK-runtime-8b/core or core.20121
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

Stack: [0x0000007f8733c000,0x0000007f8753c000],  sp=0x0000007f8753a290,  free space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J 10 C1 java.lang.String.equals(Ljava/lang/Object;)Z (81 bytes) @ 0x0000007f783acc1c [0x0000007f783acb40+0xdc]
j  javasoft.sqe.tests.vm.jvmti.fero001.fero00103.fero00103.run([Ljava/lang/String;Ljava/io/PrintStream;)I+257
j  javasoft.sqe.tests.vm.jvmti.fero001.fero00103.fero00103.main([Ljava/lang/String;)V+8
v  ~StubRoutines::call_stub
V  [libjvm.so+0x5a4264]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0xe68
V  [libjvm.so+0x5b4eac]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) [clone .isra.92]+0x268
V  [libjvm.so+0x5c4bf4]  jni_CallStaticVoidMethod+0x168
C  [libjli.so+0x7cec]  JavaMain+0x6ac
C  [libpthread.so.0+0x7c50]  start_thread+0xb0
C  [libc.so.6+0xdac60]  thread_start+0x30