JDK-8168712 : [AOT] assert(false) failed: DEBUG MESSAGE: InterpreterMacroAssembler::call_VM_base: last_sp != NULL
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-10-25
  • Updated: 2022-08-24
  • Resolved: 2017-10-24
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 8
10 b31Fixed 8u361Fixed
Related Reports
Relates :  
Description
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/macroAssembler_x86.cpp:890
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (src/cpu/x86/vm/macroAssembler_x86.cpp:890), pid=29495, tid=29498
#  assert(false) failed: DEBUG MESSAGE: InterpreterMacroAssembler::call_VM_leaf_base: last_sp != NULL
#
# JRE version: Java(TM) SE Runtime Environment (10.0) (slowdebug build 10-internal+0-adhoc.jamsheed.hs)

import java.util.*;

public class T  {
static TreeSet<T> m = new TreeSet<>();
    public static void main(String args[]) {
       int i = 0;
       while(++i<15000)test();
    }
    static T  test(){
return new T();
    }
protected void finalize() { m.add(this);}
}


option used : -XX:CompileCommand=compileonly,T.* -XX:CompileCommand=compileonly,*Object.*  -XX:+DTraceMethodProbes  -XX:-UseOnStackReplacement   -XX:+DeoptimizeRandom T

Comments
URL: http://hg.openjdk.java.net/jdk10/master/rev/bba11a95e927 User: jwilhelm Date: 2017-11-04 02:58:06 +0000
04-11-2017

URL: http://hg.openjdk.java.net/jdk10/hs/rev/bba11a95e927 User: jcm Date: 2017-10-24 16:02:03 +0000
24-10-2017

issue is there in c1/c2/aot-graal, reproducible with small test case.
21-08-2017

This crash happens because of the code in TemplateInterpreter::deopt_reexecute_entry() that uses _normal_table.entry() instead of AbstractInterpreter::deopt_reexecute_entry() if we are at a return bytecode. Normally C1 and C2 inline and use an intrinsic for Object.<init>, so there is little chance to deoptimize on a return bytecode. But with AOT-compiled Object.<init> it's possible, and we assert because we skipped the deopt entry that is supposed to clear last_sp.
19-08-2017

could reproduce the failure, with steps provided by Dean, will start working on the bug tomorrow.
03-08-2017

The hang during compilation should've been fixed with the latest Graal drop.
11-04-2017

I was able to reproduce this.
31-03-2017

This did not show up again, closing as "Cannot Reproduce".
28-03-2017

[~dpochepk] Unable to reproduce. If you are no longer able to reproduce either, pls close it.
09-03-2017

I believe you can force it to happen if you deoptimize in SharedRuntime::register_finalizer(). But you need to make sure that Object.<init> is AOT-compiled.
07-03-2017

Unless somebody can reproduce the assertion failure with current sources, I would close the bug as non-reproducible.
07-03-2017

With DeoptimizeALot the console output significantly changed but no assertion failures observed in 50 runs.
07-03-2017

How about trying -XX:+DeoptimizeRandom or -XX:+DeoptimizeALot? That might help reproduce it since it happens during deoptimization.
06-03-2017

Updated the sources, ran the test 50 times, observed no assertion failures.
04-03-2017

I'm too having troubles reproducing original failure with latest bits... I've tried both product and fastdebug builds.
03-03-2017

Do you have the latest changes, including the fix for 8173699? The fix is in jdk9 but may not have reached jdk10 yet.
03-03-2017

I got a different assertion failure running the same test with the command arguments above: # Internal Error (/export/opliss/myaotjdk/hotspot/src/share/vm/runtime/deoptimization.cpp:231), pid=29089, tid=29207 # assert(result == __null || result->is_oop()) failed: must be oop Stack backtrace: #0 0x0000003168a325e5 in raise () from /lib64/libc.so.6 #1 0x0000003168a33dc5 in abort () from /lib64/libc.so.6 #2 0x00007ffff6fc5f54 in os::abort(bool, void*, void const*) () at /export/opliss/myaotjdk/hotspot/src/os/linux/vm/os_linux.cpp:1378 #3 0x00007ffff7230d39 in VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) () at /export/opliss/myaotjdk/hotspot/src/share/vm/utilities/vmError.cpp:1359 #4 0x00007ffff7230261 in VMError::report_and_die(Thread*, char const*, int, char const*, char const*, __va_list_tag*) () at /export/opliss/myaotjdk/hotspot/src/share/vm/utilities/vmError.cpp:1128 #5 0x00007ffff6899ace in report_vm_error(char const*, int, char const*, char const*, ...) () at /export/opliss/myaotjdk/hotspot/src/share/vm/utilities/debug.cpp:220 #6 0x00007ffff68b763c in Deoptimization::fetch_unroll_info_helper(JavaThread*, int) () at /export/opliss/myaotjdk/hotspot/src/share/vm/runtime/deoptimization.cpp:231 #7 0x00007ffff68b6e52 in Deoptimization::fetch_unroll_info(JavaThread*, int) () at /export/opliss/myaotjdk/hotspot/src/share/vm/runtime/deoptimization.cpp:148 #8 0x00007fffd5d61359 in ?? () ... a few other compiled frames ...
03-03-2017

I cannot derive from these references the command line to run this test.
02-03-2017

It should not cause problems for product builds.
21-02-2017

[~dlong]/[~dpochepk], what is the impact on product builds?
21-02-2017

ILW = Assert during deoptimization with AOT code, with jvmti tests, no workaround = MMH = P3
20-02-2017

[~dlong] seem reasonable. Lets defer it
16-12-2016

[~dpochepk], I'd like to defer this to 10. Any problems with that? This is going to take more time to fix it right, and this requires JVMTI to trigger so it should have little impact on most AOT users.
15-12-2016

This seems to happen right after we enter JVMTI interpreter-only mode. j java.lang.Object.<init>()V+-42704856 java.base@9-internal The bytecode offset is a huge negative number. And there are no events printed: [error occurred during error reporting (printing ring buffers), id 0xe0000000]
30-11-2016

It looks like we are failing here in InterpreterMacroAssembler::notify_method_exit(): 1990 call_VM(noreg, 1991 CAST_FROM_FN_PTR(address, InterpreterRuntime::post_method_exit));
29-11-2016