Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8182581

aarch64: fix for crash caused by earlyret of compiled method

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 10
    • 9
    • hotspot
    • 9
    • b14
    • aarch64
    • linux

        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

              fyang Fei Yang
              fyang Fei Yang
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: