JDK-8288903 : ShouldNotReachHere() in Type::typerr() after 8284960
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19,20
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64,aarch64
  • Submitted: 2022-06-21
  • Updated: 2022-07-18
  • Resolved: 2022-06-27
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 19
19Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
The following test failed in the JDK19 CI:

applications/javafuzzer/BigTest.java

Here's a snippet from the log file:

----------System.out:(36/2672)----------
Using JRuby executable: /opt/mach5/mesos/work_dir/jib-master/install/org/jruby/jruby-dist/9.2.12.0/jruby-dist-9.2.12.0-bin.zip/jruby-9.2.12.0/bin/jruby
For random generator using seed: 4343336294702972030
To re-run test with same seed value please add "-Djdk.test.lib.random.seed=4343336294702972030" to command line.
Starting JavaFuzzer: '/bin/bash /opt/mach5/mesos/work_dir/jib-master/install/com/oracle/jpg/bigapps/javafuzzer/javafuzzer/1.0/javafuzzer-1.0.zip/mrt.sh -R /opt/mach5/mesos/work_dir/slaves/779adf21-f3e5-4e6a-a889-8cc0f9bc6fbb-S67011/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/62ef7fc2-3673-4570-a952-5fddcfaece13/runs/2189e6e6-cfc5-434b-9008-fc44700b3e1c/testoutput/test-support/jtreg_closed_test_hotspot_jtreg_applications_javafuzzer_BigTest_java/scratch/0 -NT 300 -NP 12 -A -conf config.yml'
[2022-06-21T01:07:24.563640004Z] Gathering output for process 650
[2022-06-21T11:29:16.771947361Z] Waiting for completion for process 650
[2022-06-21T11:29:16.772135246Z] Waiting for completion finished for process 650
Output and diagnostic info for process 650 was saved into 'pid-650-output.log'

Summary of the JavaFuzzer run:
------------------------------
Host:     ol7-x64-71067
Tests:    12 x 300
Args:     -conf config.yml

Started  at: Tue Jun 21 01:07:24 UTC 2022


r7- 300: 183 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 117 Reference Java failures
r5- 300: 191 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 109 Reference Java failures
r3- 300: 189 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 111 Reference Java failures
r2- 300: 193 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 107 Reference Java failures
r6- 300: 194 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 106 Reference Java failures
r8- 300: 181 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 119 Reference Java failures
r11- 300: 171 passed, 2 crashes, 0 fails, 0 hangs, 0 incorrect tests, 128 Reference Java failures
r1- 300: 184 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 116 Reference Java failures
r12- 300: 183 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 117 Reference Java failures
r4- 300: 170 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 130 Reference Java failures
r9- 300: 177 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 123 Reference Java failures
r10- 300: 177 passed, 0 crashes, 0 fails, 0 hangs, 0 incorrect tests, 123 Reference Java failures

Finished at: Tue Jun 21 11:29:16 UTC 2022


[2022-06-21T11:29:16.830814644Z] Waiting for completion for process 650
[2022-06-21T11:29:16.830998323Z] Waiting for completion finished for process 650
----------System.err:(13/728)----------
java.lang.RuntimeException: assertEquals: expected 1 to equal 2
	at jdk.test.lib.Asserts.fail(Asserts.java:594)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:205)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:189)
	at applications.javafuzzer.JavaFuzzerRunner.main(JavaFuzzerRunner.java:235)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:1596)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: assertEquals: expected 1 to equal 2

Comments
The latest crash with jdk-19+30 is a different crash: # assert(n->is_Root() || n->is_Region() || n->is_Phi() || n->is_MachMerge() || def_block->dominates(block)) failed: uses must be dominated by definitions I filed a new bug: JDK-JDK-8289954
07-07-2022

That's no problem :-)
28-06-2022

Thanks [~chagedorn]. I don't know how I missed finding that duplicate.
28-06-2022

This looks like a duplicate of JDK-8288122. I'll copy the findings to the other bug.
27-06-2022

I'm not an expert on this code, but I think the problem is ReverseBytesV was introduced, but SuperWord::output() does not recognize Op_ReverseBytes{I,L,S,US}. There may be a similar problem with ReverseV and Reverse{I,L}. [~jbhateja], please take a look.
24-06-2022

I bisected the problem to this commit: commit 6f6486e97743eadfb20b4175e1b4b2b05b59a17a (HEAD) Author: Jatin Bhateja <jbhateja@openjdk.org> Date: Tue May 31 16:02:09 2022 +0000 8284960: Integration of JEP 426: Vector API (Fourth Incubator)
24-06-2022

The assert is because AddI(LoadI, ConI) is replaced with AddI(LoadVector, ConI) and then AddNode::add_of_identity() causes TypeVect::xmeet() to be called with types vectory[8]:{int} and int:0.
24-06-2022

I can reproduce this with the attached Test.java with the flags -Xcomp -Xbatch -XX:CompileOnly=Test -XX:-TieredCompilation, starting with jdk19+25.
24-06-2022

ILW = crash; reproduces with replay fileil; -XX:DisableIntrinsic=_reverseBytes_i = HLM = P3
23-06-2022

workaround: -XX:DisableIntrinsic=_reverseBytes_i
23-06-2022