JDK-8281222 : ciTypeFlow::profiled_count fails "assert(0 <= i && i < _len) failed: illegal index"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19,repo-loom
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-02-03
  • Updated: 2022-03-31
  • Resolved: 2022-03-28
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
19 b16Fixed
Related Reports
Relates :  
JDK-8278518 - String(byte[], int, int, Charset) constructor and String.translateEscapes() miss bounds check elimination
Relates :  
JDK-8280842 - Access violation in ciTypeFlow::profiled_count
Description
The loom repo has picked up an issue after sync'ing up with jdk-19+8.

A few tests are hitting an assert in ciTypeFlow::profiled_count when the test is run in a virtual thread. So far the failures are with

java/foreign/TestSegmentCopy.java
java/text/Format/DateFormat/SimpleDateFormatPatternTest.java

In both cases the compile task is org.testng.internal.Invoker::invokeTestMethods, don't know if this coincidence but maybe it will help. jtreg uses TestNG 6.9.5 at this time.


The error log in all cases looks like:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/ws/loom/open/src/hotspot/share/utilities/growableArray.hpp:145), pid=6561, tid=34311
#  assert(0 <= i && i < _len) failed: illegal index
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-03-1408050.USER...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-03-1408050. USER..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

Current CompileTask:
C2:   4271 1957 % !   4       org.testng.internal.Invoker::invokeTestMethods @ 612 (1101 bytes)

Stack: [0x000070000db36000,0x000070000dc36000],  sp=0x000070000dc335c0,  free space=1013k
Thread 0x00007facee03cc10 [34311]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x12feac9]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e9
V  [libjvm.dylib+0x12ff14b]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x3b
V  [libjvm.dylib+0x70428d]  report_vm_error(char const*, int, char const*, char const*, ...)+0xdd
V  [libjvm.dylib+0x594afe]  ciTypeFlow::profiled_count(ciTypeFlow::Loop*)+0x51e
V  [libjvm.dylib+0x594d63]  ciTypeFlow::Loop::at_insertion_point(ciTypeFlow::Loop*, ciTypeFlow::Loop*)+0x133
V  [libjvm.dylib+0x595227]  ciTypeFlow::build_loop_tree(ciTypeFlow::Block*)+0x307
V  [libjvm.dylib+0x595c3e]  ciTypeFlow::df_flow_types(ciTypeFlow::Block*, bool, ciTypeFlow::StateVector*, ciTypeFlow::JsrSet*)+0x4de
V  [libjvm.dylib+0x595f60]  ciTypeFlow::flow_types()+0x1b0
V  [libjvm.dylib+0x596905]  ciTypeFlow::do_flow()+0x95
V  [libjvm.dylib+0x55b6fb]  ciMethod::get_osr_flow_analysis(int)+0x7b
V  [libjvm.dylib+0x1027980]  Parse::Parse(JVMState*, ciMethod*, float)+0x660
V  [libjvm.dylib+0x4efc7a]  ParseGenerator::generate(JVMState*)+0xaa
V  [libjvm.dylib+0x604e12]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1352
V  [libjvm.dylib+0x4edda7]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x167
V  [libjvm.dylib+0x622d19]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x779
V  [libjvm.dylib+0x622388]  CompileBroker::compiler_thread_loop()+0x298
V  [libjvm.dylib+0x12498b4]  JavaThread::thread_main_inner()+0x254
V  [libjvm.dylib+0x1246287]  Thread::call_run()+0x177
V  [libjvm.dylib+0xff4cc0]  thread_native_entry(Thread*)+0x150
C  [libsystem_pthread.dylib+0x6109]  _pthread_start+0x94
Comments
Changeset: 66f1da18 Author: Rickard Bäckman <rbackman@openjdk.org> Date: 2022-03-28 07:34:11 +0000 URL: https://git.openjdk.java.net/jdk/commit/66f1da188514dc111e417c7e8071f051a9c9cc9e
28-03-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7892 Date: 2022-03-21 14:45:40 +0000
21-03-2022
The key to reproducing this seems to be the version of testng. If I take the rerun script from the .jtr file, replace the jtreg version with jtreg 5.1 (using testng 6.9.5), and replace loom with jdk19, it still crashes.
04-03-2022
If I reproduce this with a loom repo, then take the replay file and run replay it with jdk19, I get the same crash.
04-03-2022
ILW = assert in c2; seems to depend on testng version; disable c2 compile of triggering method = MMM = P3
04-03-2022
It doesn't crash with jdk18 or jdk-19+7.
04-03-2022
I've reproduced it with Loom. First insight: assert(((wide ? iter.get_far_dest() : iter.get_dest()) == loop->head()->start()) == (succs->at(ciTypeFlow::GOTO_TARGET) == loop->head()), "branch should lead to loop head"); calls succs->at() when succs are empty. Printing the current block: State : locals 35, stack 0, monitors 0 local 0 : org/testng/internal/Invoker local 1 : test SimpleDateFormatPatternTest.testValidPattern("EEEE, MMMM d, yyyy h:mm:ss a z", xh): success org/testng/ITestNGMethod local 2 : org/testng/xml/XmlSuite local 3 : java/util/Map local 4 : org/testng/internal/ConfigurationGroupMethods local 5 : test SimpleDateFormatPatternTest.testValidPattern("d/M/yyyy H:mm:ss", xh): success java/lang/Object local 6 : org/testng/ITestContext local 7 : java/lang/String local 8 : java/util/Map local 9 : long test SimpleDateFormatPatternTest.testValidPattern("d-MMM-yy HH:mm:ss", xh): success local 10 : long2 local 11 : int local 12 : int local 13 : org/testng/internal/ExpectedExceptionsHolder local 14 : org/testng/ITestClass local 15 : test SimpleDateFormatPatternTest.testValidPattern("EEEE d' de 'MMMM' de 'yyyy hh:mm:ss a z", xh): success java/util/List local 16 : org/testng/internal/Invoker$FailureContext local 17 : [Lorg/testng/ITestNGMethod; local 18 : [Lorg/testng/ITestNGMethod; local 19 : long test SimpleDateFormatPatternTest.testValidPattern("yyyy'M'd' ahh'mm'ss'", xh): success local 20 : long2 local 21 : java/util/Map local 22 : org/testng/internal/Invoker$ParameterBag local 23 : java/util/Iterator local 24 : int test SimpleDateFormatPatternTest.testValidPattern("yyyy'MM'dd' EEEE ahh'mm'ss'", xh): success local 25 : java/util/List local 26 : org/testng/internal/TestResult local 27 : bottom local 28 : bottom local 29 : bottom local 30 : test SimpleDateFormatPatternTest.testValidPattern("EEEE, d MMMM yyyy HH:mm:ss z", xh): success bottom local 31 : bottom local 32 : bottom local 33 : bottom local 34 : bottom Successors : 0 Predecessors : 1 #9 test SimpleDateFormatPatternTest.testValidPattern("d/M/YYYY H:mm:ss", xh): success [445 - 455) Exceptions : 1 #1 [1028 - 1095) lphd -- java/lang/Throwable Traps on 480 with trap index 257
10-02-2022
Thanks. I tried that and I don't get the "Unable to access jarfile" error anymore but the tests pass.
04-02-2022
"Error: Unable to access jarfile /lib/jtreg.jar". I think configure needs both --with-jtreg and --with-jtregMW (MW = "Main Wrapper"). When you make run-test with JTREG_MAIN_WRAPPER then RunTests.gmk will run jtreg with the -mainWrapper option.
04-02-2022
Sorry [~roland], I didn't realize the JTREG_MAIN_WRAPPER=Virtual stuff stuff requires a custom version of jtreg. [~alanb], is there a way for Roland to get the right jtreg, or is there a way to reproduce the failure with the vanilla jtreg?
04-02-2022
The issue duplicates easily with: make run-test TEST="java/foreign/TestSegmentCopy.java" JTREG_MAIN_WRAPPER=Virtual
04-02-2022
I tied to reproduce this locally with no success. I built fastdebug for loom: commit 2af5f47e0795c763f77a09a38b25576cccbed281 (HEAD -> fibers, origin/fibers, origin/HEAD) Author: Ron Pressler <ron.pressler@oracle.com> Date: Fri Feb 4 00:21:32 2022 +0000 Remove assertion message I also rebuilt latest jtreg: commit 17bbd21a805ff0ee3a7b197613a899bd9b4b45c5 (HEAD -> master, tag: jtreg-6.2+1, origin/master, origin/HEAD) Author: Jonathan Gibbons <jjg@openjdk.org> Date: Sat Jan 22 15:30:02 2022 +0000 7903083: Provide system property or option to override timeout Reviewed-by: iris with jdk11. I run the tests with: make CONF=linux-x86_64-server-fastdebug run-test TEST="java/foreign/TestSegmentCopy.java java/text/Format/DateFormat/SimpleDateFormatPatternTest.java"
04-02-2022
The crash is past this check if (data == NULL || !data->is_JumpData()) { from JDK-8280842, so that fix doesn't seem to be the cause. This crash is because the "succs" array has length 0. [~roland], please take a look. It reproduces every time in the loom repo.
04-02-2022
Thanks for the instructions. That doesn't work though. roland@ws loom]$ make CONF=linux-x86_64-server-fastdebug run-test TEST="java/foreign/TestSegmentCopy.java" JTREG_MAIN_WRAPPER=Virtual Note: Command line contains non-control variables: * JTREG_MAIN_WRAPPER=Virtual Make sure it is not mistyped, and that you intend to override this variable. 'make help' will list known control variables. Note: Command line contains non-control variables: * JTREG_MAIN_WRAPPER=Virtual Make sure it is not mistyped, and that you intend to override this variable. 'make help' will list known control variables. Building target 'run-test' in configuration 'linux-x86_64-server-fastdebug' Test selection 'java/foreign/TestSegmentCopy.java', will run: * jtreg:test/jdk/java/foreign/TestSegmentCopy.java Running test 'jtreg:test/jdk/java/foreign/TestSegmentCopy.java' Error: Unable to access jarfile /lib/jtreg.jar Finished running test 'jtreg:test/jdk/java/foreign/TestSegmentCopy.java' Test report is stored in build/linux-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_foreign_TestSegmentCopy_java ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/jdk/java/foreign/TestSegmentCopy.java 1 0 0 1 << ============================== TEST FAILURE make[1]: *** [/home/roland/loom/make/Init.gmk:319: main] Error 1 make: *** [/home/roland/loom/make/Init.gmk:186: run-test] Error 2 The test does run without JTREG_MAIN_WRAPPER=Virtual jtreg is built from: commit f9c46f2d78bdc0b4077ff17e9cb6ccff1ee0157a (HEAD -> loom, origin/loom) Author: lmesnik <leonid.mesnik@oracle.com> Date: Tue Nov 30 14:19:54 2021 -0700 -agentvm mode fixed
04-02-2022
[~dlong] Yeah, the setup is complicated. I'm trying to see if I can duplicate it with a simpler setup. I've created a 10-line program that runs TestNG directly. This requires jtreg from the picture. So far all 279794 test cases run by these 2 tests pass when executed with both platform and virtual threads.
04-02-2022
Loom is currently using a fork of jtreg that provides a way to run existing tests in the context of virtual thread, the repo to use is: git clone -b loom https://github.com/lmesnik/jtreg TBD if this execution mode will ever make it into the jtreg main line. The build needs to be configured to use this jtreg build, then add JTREG_MAIN_WRAPPER=Virtual to make run-test command to execute the test in a virtual thread. The assert triggers every time for me with the two tests.
04-02-2022