JDK-8251458 : Parse::do_lookupswitch fails with "assert(_cnt >= 0) failed"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14,15,16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-12
  • Updated: 2024-11-20
  • Resolved: 2020-08-13
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 JDK 16
11.0.10-oracleFixed 15.0.2Fixed 16 b12Fixed
Related Reports
Relates :  
Relates :  
Description
The following test failed in the JDK16 CI:

applications/dacapo/Dacapo24H.java

Here's a snippet from the log file:

[2020-08-11T21:49:06.956031148Z] Gathering output for process 7716
[2020-08-11T21:49:08.971282128Z] Waiting for completion for process 7716
[2020-08-11T21:49:08.971573437Z] Waiting for completion finished for process 7716
Output and diagnostic info for process 7716 was saved into 'pid-7716-output.log'
[2020-08-11T21:49:08.973894788Z] Waiting for completion for process 7716
[2020-08-11T21:49:08.973952798Z] Waiting for completion finished for process 7716
[stress.process.out] #
[stress.process.out] # A fatal error has been detected by the Java Runtime Environment:
[stress.process.out] #
[stress.process.out] #  Internal Error (/opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S170/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/196f2dcf-68ed-4a11-8800-10f95ee8a7a5/runs/94cff4f6-eeed-4e7c-92d4-daf613c186d8/workspace/open/src/hotspot/share/opto/parse2.cpp:329), pid=11907, tid=22347
[stress.process.out] #  Error: assert(_cnt >= 0) failed
[stress.process.out] #
[stress.process.out] # JRE version: Java(TM) SE Runtime Environment (16.0+11) (fastdebug build 16-ea+11-386)
[stress.process.out] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-ea+11-386, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
[stress.process.out] # Problematic frame:
[stress.process.out] # V  [libjvm.so+0x142147c]  Parse::do_lookupswitch()+0x58c
[stress.process.out] #
[stress.process.out] # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S39/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7b57845f-d02e-4d07-859e-b468beca682c/runs/1161fa51-1c39-427a-8f9d-d38efbe4f6f3/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/core.11907)
[stress.process.out] #
[stress.process.out] Unsupported internal testing APIs have been used.
[stress.process.out] 
[stress.process.out] # An error report file with more information is saved as:
[stress.process.out] # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S39/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7b57845f-d02e-4d07-859e-b468beca682c/runs/1161fa51-1c39-427a-8f9d-d38efbe4f6f3/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/hs_err_pid11907.log
[stress.process.out] #
[stress.process.out] # Compiler replay data is saved as:
[stress.process.out] # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S39/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/7b57845f-d02e-4d07-859e-b468beca682c/runs/1161fa51-1c39-427a-8f9d-d38efbe4f6f3/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_dacapo_Dacapo24H_java/scratch/0/replay_pid11907.log
[stress.process.out] #
[stress.process.out] # If you would like to submit a bug report, please visit:
[stress.process.out] #   https://bugreport.java.com/bugreport/crash.jsp
[stress.process.out] #


Stress process failed. See stress.process.err/stress.process.out files for details.


Here's the crashing thread's stack:

---------------  T H R E A D  ---------------

Current thread (0x00007f70a11f7680):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=22347, stack(0x00007f70a90e8000,0x00007f70a91e9000)]


Current CompileTask:
C2:86672490 4214870 %     4       org.eclipse.jdt.internal.core.index.DiskIndex::readStreamChars @ 130 (485 bytes)

Stack: [0x00007f70a90e8000,0x00007f70a91e9000],  sp=0x00007f70a91e5c90,  free space=1015k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x142147c]  Parse::do_lookupswitch()+0x58c
V  [libjvm.so+0x1424a78]  Parse::do_one_bytecode()+0x2f78
V  [libjvm.so+0x140f641]  Parse::do_one_block()+0x601
V  [libjvm.so+0x141052d]  Parse::do_all_blocks()+0x11d
V  [libjvm.so+0x1414aa4]  Parse::Parse(JVMState*, ciMethod*, float)+0xbd4
V  [libjvm.so+0x74ff15]  ParseGenerator::generate(JVMState*)+0x115
V  [libjvm.so+0x8fe976]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0xc66
V  [libjvm.so+0x74e2e4]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x184
V  [libjvm.so+0x90e8d0]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xde0
V  [libjvm.so+0x90f698]  CompileBroker::compiler_thread_loop()+0x6b8
V  [libjvm.so+0x16c692f]  JavaThread::thread_main_inner()+0x22f
V  [libjvm.so+0x16cbf40]  Thread::call_run()+0x100
V  [libjvm.so+0x13d0876]  thread_native_entry(Thread*)+0x116
Comments
Fix Request (15u) This fixes the regression introduced in 11. Patch applies cleanly to 15u, new test fails without the patch and passes with it. tier{1,2} pass with the patch.
09-09-2020

Fix Request (11u) This fixes the regression introduced in 11. Patch applies cleanly to 11u, new test fails without the patch and passes with it. tier{1,2} pass with the patch.
08-09-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/99da356b565b User: thartmann Date: 2020-08-13 14:02:09 +0000
13-08-2020

We hit an assert in Parse::do_lookupswitch() because the "taken" counter for a lookupswitch branch is negative. The problem is an overflow when converting an uint counter value > max_jint from profile information to a jint. The fix is to handle such overflows by simply limiting the counter value to max_jint: http://cr.openjdk.java.net/~thartmann/8251458/webrev.00/
12-08-2020

Code was introduced by JDK-8200303. I can reproduce the issue with replay compilation. ILW = Assert during C2 compilation, intermittent but reproducible with replay compilation, -XX:-UseSwitchProfiling = HLM = P3
12-08-2020