JDK-8271055 : Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,11,16,17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-07-21
  • Updated: 2024-07-22
  • Resolved: 2022-02-03
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 17 JDK 18 JDK 19
11.0.16-oracleFixed 17.0.4-oracleFixed 18.0.2Fixed 19 b09Fixed
Related Reports
Relates :  
JDK-8336906 - C2: assert(bb->is_reachable()) failed: getting result from unreachable basicblock
Relates :  
JDK-8074292 - nsk/jdb/kill/kill001: generateOopMap.cpp assert(bb->is_reachable()) failed
Description
The attached Java Fuzzer test crashes with the following assertion:

To reproduce:
$ java -XX:+VerifyStack Test.java
$ java -XX:+VerifyStack Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S124123/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/57294efe-464f-4c0a-b55a-fd67bfa32e7b/runs/71c23d41-87fd-4de4-92b5-4ba130c3e1dd/workspace/open/src/hotspot/share/oops/generateOopMap.cpp:2216), pid=2766569, tid=2766570
#  assert(bb->is_reachable()) failed: getting result from unreachable basicblock
#
# JRE version: Java(TM) SE Runtime Environment (18.0+7) (fastdebug build 18-ea+7-268)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+7-268, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xd349cc]  GenerateOopMap::result_for_basicblock(int)+0x9c
..........
Command Line: -XX:CompileCommand=quiet -XX:CompileCommand=dontinline,Test::* -XX:+VerifyOops -XX:+VerifyStack -XX:+VerifyLastFrame -XX:+VerifyBeforeGC -XX:+VerifyAfterGC -XX:+VerifyDuringGC -XX:+VerifyAdapterSharing Test
..........
Current thread (0x00007f5934029370):  JavaThread "main" [_thread_in_Java, id=2766570, stack(0x00007f593d827000,0x00007f593d928000)]

Stack: [0x00007f593d827000,0x00007f593d928000],  sp=0x00007f593d9242c0,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xd349cc]  GenerateOopMap::result_for_basicblock(int)+0x9c
V  [libjvm.so+0x1530e2e]  OopMapForCacheEntry::compute_map(Thread*)+0x17e
V  [libjvm.so+0x1532ad1]  OopMapCacheEntry::fill(methodHandle const&, int)+0xf1
V  [libjvm.so+0x15333c3]  OopMapCache::compute_one_oop_map(methodHandle const&, int, InterpreterOopMap*)+0x63
V  [libjvm.so+0xa9edcc]  Deoptimization::unpack_frames(JavaThread*, int)+0xaec
v  ~DeoptimizationBlob
j  Test.iMeth(II)I+346
j  Test.vMeth1(II)V+86
j  Test.vMeth(IJJ)V+119
j  Test.mainTest([Ljava/lang/String;)V+72
j  Test.main([Ljava/lang/String;)V+18
v  ~StubRoutines::call_stub
V  [libjvm.so+0xe5f8f4]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x504
V  [libjvm.so+0xf91c95]  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) [clone .constprop.1]+0x375
V  [libjvm.so+0xf953a5]  jni_CallStaticVoidMethod+0x1c5
C  [libjli.so+0x47e7]  JavaMain+0xd37
C  [libjli.so+0x7d19]  ThreadJavaMain+0x9

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~DeoptimizationBlob
j  Test.iMeth(II)I+346
j  Test.vMeth1(II)V+86
j  Test.vMeth(IJJ)V+119
j  Test.mainTest([Ljava/lang/String;)V+72
j  Test.main([Ljava/lang/String;)V+18
v  ~StubRoutines::call_stub
Comments
Fix request [11u] I backport this for parity with 11.0.16-oracle. No risk, only a change to debug coding. Clean backport. Test passes. SAP nightly testing passes.
07-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/1004 Date: 2022-04-05 15:42:59 +0000
05-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk18u/pull/67 Date: 2022-03-29 15:24:24 +0000
29-03-2022
Fix Request (JDK 18u) Fixes an assert during stack verification. The fix is low risk and applies cleanly. Already tested and backported to Oracle JDK 17u. Tier 1-3 testing is running for JDK 18u.
29-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk17u-dev/pull/298 Date: 2022-03-29 13:04:38 +0000
29-03-2022
Fix Request (17u): Should get backported for parity with 17.0.4-oracle. Applies cleanly. Test has passed.
29-03-2022
Hi [~dlong], the fix looks reasonable to me.
04-03-2022
Changeset: e44dc638 Author: Dean Long <dlong@openjdk.org> Date: 2022-02-03 22:10:44 +0000 URL: https://git.openjdk.java.net/jdk/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c
03-02-2022
Testing with fix enabled: https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-fix-20220203-0404-28760219 https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-fix-20220203-0404-28760250 https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-fix-20220203-0405-28760277 https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-fix-20220203-0423-28760836
03-02-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7331 Date: 2022-02-03 04:11:38 +0000
03-02-2022
Baseline testing with new test and fix disabled: MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-baseline-20220203-0352-28759881 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-baseline-20220203-0353-28759908 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-baseline-20220203-0354-28759939 MDash: https://mach5.us.oracle.com/mdash/jobs/dlong-8271055-baseline-20220203-0355-28759966
03-02-2022
Test.java still fails for me. When I run in gdb, it says the current bytecode is Bytecodes::_goto. If that's always the case, the fix is simple. We shouldn't be computing the stack state for next instruction if the current instruction doesn't fall through. The current code has a special case for Bytecodes::_athrow, so it makes sense to also check for other instructions that don't fall through. 804 if (!Bytecodes::is_invoke(cur_code) && cur_code != Bytecodes::_athrow) { [~yyang], can you confirm my findings?
02-02-2022
Thanks for the detailed summary Yi! It seems that this is not so easy to fix and requires quite some changes in code for the debug build flag VerifyStack. I'll re-target it to 19 for now. If you, or someone else, still want to pick this up 18, please move it back to 18 again.
17-11-2021
Hi [~chagedorn], this is a debug flag, it does not affect the product environment, I'm not sure if I have time to investigate and fix this problem in jdk18, so I clear the assignee, anyone who is interested in this problem (including me) can also investigate it later. Some thoughts(IIRC): The root cause is that javac generates unreachable blocks and there is no exception table for that method, thus hitting the assertions when turning VerifyStack on. Since JDK-8271254 is fixed, I think the attached test should not trigger the assertion anymore. But JDK-8271254 is not enough for this problem, because it only fixes a javac bug that emits unreachable blocks, people can still generate problematic bytecodes in other ways. (I'm not quite sure, maybe JDK-8271254 generates unreadable blocks with an exception table, maybe it does not generate unreachable blocks, but the conclusion is still valid, i.e. people can still generate problematic bytecodes in other ways). To fix this, we might change many codes around VerifyStack, because VerifyStack thinks they are really unreachable(no exception table and unreachable from CFG perspective), but they are actually reachable(logically in code, `catch` would be reachable if `try` throws exceptions). Thanks.
17-11-2021
Hi [~yyang], as the fork's soon coming up in early December, are you planing to get this fixed in 18? Otherwise, it needs to be deferred to 19 once RDP 1 starts (because it's a P4).
16-11-2021
[~yyang] Bug JDK-8074292 happened 4 times, in 2015, 2019 and 2 times in 2020. We/I spent a lot of time on this and couldn't reproduce it either. This bug is a different stack trace, but same symptom. All the data from it is gone now. Looking at the fix, it seems it might fix this bug also, but I honestly don't know.
27-07-2021
No problem :-)
27-07-2021
Sorry for Christian that I started work on this w/o any sync earlier. I will take care of this in the furuter;-)
27-07-2021
[~coleenp] I tried JDK-8074292 many times but still can not trigger the assertion. I'm glad to investigate it if there is a reliable reproducible test case. Otherwise, we can see if the crash still occurs after removing trap bytecode checking.
27-07-2021
I just linked a bug that we thought was due to an async exception, that we don't think is possible. Could this be the root cause of JDK-8074292 also? We've been chasing that one for years.
26-07-2021
ILW = Assert in deoptimization when using VerifyStack flag, seen multiple times so far, use -XX:-VerifyStack = MML = P4
21-07-2021