JDK-8298720 : Insufficient error handling when CodeBuffer is exhausted
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,17,20,21
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2022-12-14
  • Updated: 2023-01-09
  • Resolved: 2023-01-06
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 21
21 masterFixed
Related Reports
Relates :  
JDK-8299570 - [JVMCI] Insufficient error handling when CodeBuffer is exhausted
Relates :  
JDK-8130309 - Need to bailout cleanly if creation of stubs fails when codecache is out of space
Relates :  
JDK-8287129 - TestStressCodeBuffers.java crashes on macosx_aarch64
Relates :  
JDK-8272094 - compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline"
Relates :  
JDK-8248411 - AArch64: Insufficient error handling when CodeBuffer is exhausted
Description
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010906423c, pid=26207, tid=22019
#
# JRE version: Java(TM) SE Runtime Environment 18.9 (11.0.19+1) (fastdebug build 11.0.19-ea+1-LTS-101)
# Java VM: Java HotSpot(TM) 64-Bit Server VM 18.9 (fastdebug 11.0.19-ea+1-LTS-101, compiled mode, compressed oops, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x6423c]  Assembler::emit_long(int)+0x34

Current CompileTask:
C2:   1602  487    b        java.lang.String::indexOf (113 bytes)

Stack: [0x000000016cadc000,0x000000016ccdf000],  sp=0x000000016ccdac10,  free space=2043k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x6423c]  Assembler::emit_long(int)+0x34
V  [libjvm.dylib+0x641b0]  Assembler::emit()+0x1c
V  [libjvm.dylib+0x67720]  Assembler::b(unsigned char*)+0xb8
V  [libjvm.dylib+0x7bbd0c]  MacroAssembler::string_indexof(RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, int, RegisterImpl*, int)+0x14b8
V  [libjvm.dylib+0x4dc04]  string_indexofLLNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x33c
V  [libjvm.dylib+0x8a6f20]  Compile::fill_buffer(CodeBuffer*, unsigned int*)+0xe00
V  [libjvm.dylib+0x2ea25c]  Compile::Code_Gen()+0x3c8
V  [libjvm.dylib+0x2e7cb4]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0xa18
V  [libjvm.dylib+0x1fdcf0]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x154
V  [libjvm.dylib+0x2fafec]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x434
V  [libjvm.dylib+0x2faa24]  CompileBroker::compiler_thread_loop()+0x1ec
V  [libjvm.dylib+0xa2c568]  JavaThread::thread_main_inner()+0x1f8
V  [libjvm.dylib+0xa2c020]  JavaThread::run()+0x32c
V  [libjvm.dylib+0xa28b90]  Thread::call_run()+0x90
V  [libjvm.dylib+0x896874]  thread_native_entry(Thread*)+0x11c
C  [libsystem_pthread.dylib+0x7878]  _pthread_start+0x140


Test: TestStressCodeBuffers.java
OS: macosx-aarch64-debug
Where: 11.0.19-oracle

#-----testresult-----
description=file\:/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-11.0.19+1-101/src.full/open/test/hotspot/jtreg/compiler/codecache/TestStressCodeBuffers.java
elapsed=4570 0\:00\:04.570
end=Tue Dec 13 12\:22\:05 GMT 2022
environment=regtest
execStatus=Failed. Unexpected exit from test [exit code\: 134]
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=jpg-mac-arm-27.oraclecorp.com
javatestOS=Mac OS X 11.6.6 (aarch64)
javatestVersion=6.0-ea+b11-2020-05-19
jtregVersion=jtreg 5.1 ea b01
script=com.sun.javatest.regtest.exec.RegressionScript
sections=script_messages build compile main
start=Tue Dec 13 12\:22\:00 GMT 2022
test=compiler/codecache/TestStressCodeBuffers.java
testJDK=/System/Volumes/Data/mesos/work_dir/jib-master/install/jdk-11.0.19+1-101/macosx-aarch64-debug.jdk/jdk-11.0.19/fastdebug
Comments
Changeset: cc4936a7 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2023-01-06 08:28:09 +0000 URL: https://git.openjdk.org/jdk/commit/cc4936a79e1c1723542d575a2596edd29248817e
06-01-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11839 Date: 2023-01-04 06:31:16 +0000
04-01-2023
I attached a prototype patch. Will complete this after the winter break.
23-12-2022
After strengthening -XX:+StressCodeBuffers, I can reproduce the issue in mainline with a slightly different stack trace: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000001048abf44, pid=71594, tid=41475 # # JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2022-12-22-1203593.tohartma...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2022-12-22-1203593.tohartma..., compiled mode, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # V [libjvm.dylib+0xf3f44] Assembler::b(unsigned char*)+0xb8 Current CompileTask: C2: 2369 26 b java.lang.String::indexOf (113 bytes) Stack: [0x000000016ec0c000,0x000000016ee0f000], sp=0x000000016ee09cc0, free space=2039k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xf3f44] Assembler::b(unsigned char*)+0xb8 V [libjvm.dylib+0x3bc9b0] C2_MacroAssembler::string_indexof(Register, Register, Register, Register, Register, Register, Register, Register, Register, Register, int, Register, int)+0x13dc V [libjvm.dylib+0x78b8c] string_indexofULNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x6bc V [libjvm.dylib+0xdb27f0] PhaseOutput::fill_buffer(CodeBuffer*, unsigned int*)+0x13d0 V [libjvm.dylib+0x4d822c] Compile::Code_Gen()+0x3b4 V [libjvm.dylib+0x4d5eb0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x15b4 V [libjvm.dylib+0x3cc09c] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x180 V [libjvm.dylib+0x4f2260] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x56c V [libjvm.dylib+0x4f1b20] CompileBroker::compiler_thread_loop()+0x288 V [libjvm.dylib+0x89c520] JavaThread::thread_main_inner()+0x20c V [libjvm.dylib+0xfda94c] Thread::call_run()+0x220 V [libjvm.dylib+0xda0eb0] thread_native_entry(Thread*)+0x160 C [libsystem_pthread.dylib+0x74ec] _pthread_start+0x94
22-12-2022
If found the root cause which is missing checks of the return value of trampoline_call in MacroAssembler::string_indexof. This was missed by JDK-8248411 which fixed many other similar places.
21-12-2022
My current working hypothesis is that, similar to JDK-8257513, we miss a compilation bailout when StressCodeBuffers simulates an occasional allocation failure. Below log shows that we are compiling task 487 which then triggers an allocation failure but the hs_err file shows that we continued to emit code because we are still compiling task 487 when we fail. 1445 0 487 b java.lang.String::indexOf([BBILjava/lang/String;I)I (113 bytes) - java.lang.String::coder()B (15 bytes) - java.lang.String::length()I (11 bytes) - java.lang.String::coder()B (15 bytes) Values: 295 nodes ---> 0/0 (0) Values: 295 nodes ---> 4/27 (0) ratio 0.148148 expanding CodeBuffer:CodeBuffer: consts.code = 0x000000010db2ae00 : 0x000000010db2ae00 : 0x000000010db2ae18 (0 of 24) consts.locs = 0x00000001193f8ea0 : 0x00000001193f8ea0 : 0x00000001193f8ea8 (0 of 4) point=0 insts.code = 0x000000010db2abc0 : 0x000000010db2abc0 : 0x000000010db2ad40 (0 of 384) insts.locs = 0x00000001193f8e00 : 0x00000001193f8e00 : 0x00000001193f8e9a (0 of 77) point=0 stubs.code = 0x000000010db2ad80 : 0x000000010db2ad80 : 0x000000010db2adc0 (0 of 64) stubs.locs = 0x00000001193f8eb0 : 0x00000001193f8eb0 : 0x00000001193f8eb8 (0 of 4) point=0 expanded CodeBuffer:CodeBuffer: consts.code = 0x000000010db30ac0 : 0x000000010db30ac0 : 0x000000010db30b00 (0 of 64) consts.locs = 0x00000001193f8ea0 : 0x00000001193f8ea0 : 0x00000001193f8ea8 (0 of 4) point=0 insts.code = 0x000000010db304c0 : 0x000000010db304c0 : 0x000000010db30a80 (0 of 1472) insts.locs = 0x00000001193f8e00 : 0x00000001193f8e00 : 0x00000001193f8e9a (0 of 77) point=0 stubs.code = 0x000000010db30b40 : 0x000000010db30b40 : 0x000000010db30b80 (0 of 64) stubs.locs = 0x00000001193f8eb0 : 0x00000001193f8eb0 : 0x00000001193f8eb8 (0 of 4) point=0 expanding CodeBuffer:CodeBuffer: consts.code = 0x000000010db30ac0 : 0x000000010db30ac0 : 0x000000010db30b00 (0 of 64) consts.locs = 0x00000001193f8ea0 : 0x00000001193f8ea0 : 0x00000001193f8ea8 (0 of 4) point=0 insts.code = 0x000000010db304c0 : 0x000000010db3067c : 0x000000010db30a80 (444 of 1472) insts.locs = 0x00000001193f8e00 : 0x00000001193f8e04 : 0x00000001193f8e9a (2 of 77) point=136 stubs.code = 0x000000010db30b40 : 0x000000010db30b50 : 0x000000010db30b80 (16 of 64) stubs.locs = 0x0000000119321b50 : 0x0000000119321b56 : 0x0000000119321b6e (3 of 15) point=0 StressCodeBuffers: have expanded 1024 times Current CompileTask: C2: 1448 2 2 487 b java.lang.String::indexOf([BBILjava/lang/String;I)I (113 bytes) Stack: [0x0000000170a10000,0x0000000170c13000], sp=0x0000000170c0ec10, free space=2043k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0x6423c] Assembler::emit_long(int)+0x34 V [libjvm.dylib+0x641b0] Assembler::emit()+0x1c V [libjvm.dylib+0x67720] Assembler::b(unsigned char*)+0xb8
19-12-2022
We are in CodeSection::emit_int32 and somehow CodeSection::_end ended up being x8=0xfffffffffffffffe which is #define badAddress ((address)::badAddressVal) 0x1065c0234 <+44>: ldr x0, [x8, #0x18] 0x1065c0238 <+48>: ldr x8, [x0, #0x10] 0x1065c023c <+52>: str w1, [x8]
19-12-2022
This looks suspicious: enum ScratchBufferBlob { #if defined(PPC64) MAX_inst_size = 2048, #else MAX_inst_size = 1024, #endif In mainline, since JDK-8230565, we always have MAX_inst_size = 2048 I'll take a closer look. Update: If the ScratchBufferBlob is too small, we would fail with an assert: # Internal Error (workspace/open/src/hotspot/share/asm/codeBuffer.hpp:184), pid=5551, tid=43267 # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x000000011816a140 <= 0x000000011816a2c4 <= 0x000000011816a2c0 V [libjvm.dylib+0xab2c80] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x5b0 V [libjvm.dylib+0xab33f8] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x40 V [libjvm.dylib+0x379354] report_vm_error(char const*, int, char const*, char const*, ...)+0x74 V [libjvm.dylib+0x63c9c] CodeSection::set_end(unsigned char*)+0x84 V [libjvm.dylib+0x63b78] Assembler::emit()+0x1c V [libjvm.dylib+0x64b90] Assembler::ld_st2(RegisterImpl*, Address const&, int, int, int)+0x1b8 V [libjvm.dylib+0x7bb520] MacroAssembler::string_indexof(RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, RegisterImpl*, int, RegisterImpl*, int)+0xfe8 V [libjvm.dylib+0x4d5cc] string_indexofLLNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x33c V [libjvm.dylib+0x8a6c04] Compile::fill_buffer(CodeBuffer*, unsigned int*)+0xe00 So this must be something else.
15-12-2022
ILW = Segfault in C2 code generation, single test on mac aarch64, disable compilation of affected method = HLM = P3
15-12-2022
This was already reported by JDK-8287129 with an earlier version and closed as duplicate of JDK-8272094. Now that we have the fix for JDK-8272094 in JDK 11.0.18-oracle, it must be a different issue.
14-12-2022