JDK-8328085 : C2: Use after free in PhaseChaitin::Register_Allocate()
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7,8,11,17,21,22,23,24
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • CPU: ppc,x86_64
  • Submitted: 2024-03-13
  • Updated: 2025-09-03
  • Resolved: 2024-11-21
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 17 JDK 21 JDK 24
17.0.15Fixed 21.0.10-oracleFixed 24 b26Fixed
Related Reports
Relates :  
JDK-8068881 - SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions.
Relates :  
JDK-8336095 - Use-after-free in Superword leads to memory corruption
Relates :  
JDK-8337015 - Revisit resource arena allocations in C2
Relates :  
JDK-8344609 - Check ResourceMark nesting when allocating a GrowableArray on an alternative ResourceArea
Relates :  
JDK-8328165 - improve assert(idx < _maxlrg) failed: oob
Description
We have seen the assertion  
assert(idx < _maxlrg) failed: oob
in vmTestbase/vm/mlvm/indy/func/java/verifyStackTrace/INDIFY_Test.java
2 times in last months on AIX ppc64,  now also on Windows x86_64 .

#  Internal Error (/priv/jenkins/client-home/workspace/openjdk-22u-aix_ppc64-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=8192474, tid=4805
#  assert(idx < _maxlrg) failed: oob
#

Stack: [0x0000000125550000,0x000000012594d888],  sp=0x0000000125949ed0,  free space=4071k
No context given, using current context.
Native frame:
iar:  0x0900000003ede16c libjvm.so::AixNativeCallstack::print_callstack_for_context(outputStream*, ucontext_t const*, bool, char*, unsigned long)+0x4cc  (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:5 parmsonstk:1)
lr:   0x09000000039bc9b4 libjvm.so::fdStream::write(char const*, unsigned long)+0x44  (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:3 parmsonstk:1)
sp:   0x0000000125949190 (base - 0x46F8) 
rtoc: 0x08001000a03da400 
|---stackaddr----|   |----lrsave------|:   <function name>
0x0000000125949580 - 0x0900000003eddc2c libjvm.so::os::Aix::platform_print_native_stack(outputStream*, void const*, char*, int, unsigned char*&)+0x24  (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:5 parmsonstk:1)
0x0000000125949600 - 0x09000000039cd348 libjvm.so::VMError::report(outputStream*, bool)+0x1c0c  (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:2 parmsonstk:1)
0x0000000125949ee0 - 0x09000000039bbdc8 libjvm.so::VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x7cc  (C++ uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:8 parmsonstk:1)
0x000000012594a0d0 - 0x09000000039bb5b0 libjvm.so::VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x58  (C++ uses_alloca saves_lr stores_bc gpr_saved:2 fixedparms:7 parmsonstk:1)
0x000000012594a170 - 0x09000000039bb290 libjvm.so::report_vm_error(char const*, int, char const*, char const*, ...)+0x8c  (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:4 parmsonstk:1)
0x000000012594a210 - 0x09000000047807ec libjvm.so::PhaseChaitin::Register_Allocate()+0x10a0  (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1)
0x000000012594a5c0 - 0x090000000475fc64 libjvm.so::Compile::Code_Gen()+0x21c  (C++ uses_alloca saves_lr stores_bc gpr_saved:6 fixedparms:1 parmsonstk:1)
0x000000012594b200 - 0x09000000047dd12c libjvm.so::Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x16c4  (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1)
0x000000012594be70 - 0x09000000049ec7a8 libjvm.so::C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x25c  (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1)
0x000000012594ca90 - 0x0900000003cffb44 libjvm.so::CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcb4  (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1)
0x000000012594d210 - 0x0900000003cf0264 libjvm.so::CompileBroker::compiler_thread_loop()+0x4c0  (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 parmsonstk:1)
0x000000012594d460 - 0x0900000003cefd24 libjvm.so::CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x58  (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:2 parmsonstk:1)
0x000000012594d4e0 - 0x0900000003b8ef84 libjvm.so::JavaThread::thread_main_inner()+0x1f8  (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:1 parmsonstk:1)
0x000000012594d5b0 - 0x0900000003b8d06c libjvm.so::JavaThread::run()+0x214  (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:1 parmsonstk:1)
0x000000012594d650 - 0x0900000003abb85c libjvm.so::Thread::call_run()+0x128  (C++ uses_alloca saves_lr stores_bc gpr_saved:3 fixedparms:1 parmsonstk:1)
0x000000012594d6e0 - 0x0900000003abad50 libjvm.so::thread_native_entry(Thread*)+0x194  (C++ uses_alloca saves_lr stores_bc gpr_saved:9 fixedparms:1 parmsonstk:1)
0x000000012594d7a0 - 0x090000000056204c libpthreads.a::_pthread_body+0xec  (C saves_lr stores_bc gpr_saved:1 fixedparms:1 )
0x000000012594d820 - 0x0000000000000000 
*** end of backchain ***

*UPDATE 2024-10-04*

Several crash logs show the  badResourceValue pattern (abababab r7 below). That indicates a use-after-free issue with memory allocated from the ResourceArea similar to JDK-8336095.

pc =0x00007fffa8a3ed70  lr =0x00007fffa8a545b4  ctr=0x00007fffaaef89b0  
r0 =0x00007fffa8a545b4  r1 =0x00007ffe2a9faf00  r2 =0x00007fffaa8b0f00  
r3 =0x00007fffaa1e0448  r4 =0x0000000000000127  r5 =0x00007fffaa1e0428  
r6 =0x00007fffaa1e0400  r7 =0x00000000abababab  r8 =0x0000000000000058  
r9 =0x00007ffe2a9fb0c0  r10=0x00007fffaae50000  r11=0x00007fffa9a599a0  
r12=0x00007fffaaef89b0  r13=0x00007ffe2aa068e0  r14=0x0000000000000003  
r15=0x0000000000000010  r16=0x0000000000000000  r17=0x00007fffaa964bb0  
r18=0x00007ffe2a9fb638  r19=0x00007ffe2a9fb080  r20=0x00007fffaa1e22f0  
r21=0x00007ffe2a9fb4f0  r22=0x0000000000000001  r23=0x00007ffe2a9fb010  
r24=0x00007ffe2a9fb088  r25=0x00007fffaa93ff20  r26=0x0000000000000000  
r27=0x000000000000002f  r28=0x00007fffaa932170  r29=0x00007ffe2a9fb048  
r30=0x00007ffe2a9fb4c8  r31=0x00007ffe2a9faf00  

*UPDATE 2024-11-04*

Several crash logs have messages similar to

#  assert(idx < _maxlrg) failed: oob: index 2880154539 not smaller than 131

The index 2880154539 in hexadecimal format is abababab. This means that badResourceValue isn't just coincidentally near data used by the program but abababab is actually data used by the program (as variable `idx`). That is a strong indication for a use-after-free bug.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3197 Date: 2025-01-09 14:37:36 +0000
13-01-2025
Fix request (17u) I would like to backport the fix because we had 2 crashes with the same symptoms now also in our 17u-dev testing on ppc64le. The backport is clean. I'd consider the risk medium. There could be scenarios with higher memory usage in c2 register allocation. DaCapo tests were ok (see pull request). The fix passed our CI testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. JCK, SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests. Testing was done with fastdebug builds on the main platforms and also on Linux/PPC64le and AIX.
13-01-2025
Fix request (21u) I would like to do the backport because we see crashes on ppc64 because of the use-after-free. The backport is clean (according to the bot). Doing it I actually had to resolve a minimal contextual conflict because the TracePhase constructor was changed. I'd consider the risk medium. There could be scenarios with higher memory usage in c2 register allocation. DaCapo tests were ok (see pull request). The fix passed our CI testing: JTReg tests: tier1-4 of hotspot and jdk. All of Langtools and jaxp. JCK, SPECjvm2008, SPECjbb2015, Renaissance Suite, and SAP specific tests. Testing was done with fastdebug builds on the main platforms and also on Linux/PPC64le and AIX.
13-12-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1217 Date: 2024-12-10 08:47:30 +0000
12-12-2024
Changeset: 93aa7e2f Branch: master Author: Richard Reingruber <rrich@openjdk.org> Date: 2024-11-21 06:57:09 +0000 URL: https://git.openjdk.org/jdk/commit/93aa7e2fcf87c4dc62de4ea71be543ee677b11be
21-11-2024
[~thartmann] I've create JDK-8344609 The nesting check fails running test/hotspot/jtreg/applications/ctw/modules/java_desktop.java with the draft-pr: https://github.com/openjdk/jdk/pull/22269 But only on ppc not on x86_64.
20-11-2024
Okay, thanks for confirming!
20-11-2024
> So this is a regression from JDK-8068881, correct? Yes, I think so. Pretty old bug, if true. We've seen this also in 21 but not in older releases. Crashes happen mostly with applications/ctw/modules/java_desktop.java. Can't find a crash on another platform than ppc. > > I think the nesting check can be generalized for arbitrary ResourceAreas (will create a RFE). > > Did you create an RFE yet? Not yet. I started experimenting a little bit. Will create an RFE later.
19-11-2024
So this is a regression from JDK-8068881, correct? > I think the nesting check can be generalized for arbitrary ResourceAreas (will create a RFE). Did you create an RFE yet?
19-11-2024
> [~thartmann] have you maybe seen crashes with the badResourceValue pattern recently? Sorry [~rrich], I missed your message. No, that doesn't ring a bell.
19-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22200 Date: 2024-11-18 10:53:41 +0000
19-11-2024
The issues are most likely caused by the ResourceMark in PhaseChaitin::merge_multidefs. https://github.com/openjdk/jdk/blob/b9c6ce900b512adfcaccd2341be3eb0003a28b87/src/hotspot/share/opto/postaloc.cpp#L405 The ResourceMark frees memory allocated when expanding the growable array PhaseChaitin::_lrg_map::_names in the callee PhaseChaitin::possibly_merge_multidef. https://github.com/openjdk/jdk/blob/b9c6ce900b512adfcaccd2341be3eb0003a28b87/src/hotspot/share/opto/postaloc.cpp#L457 The freed memory is accessed in the caller PhaseChaitin::Register_Allocate. https://github.com/openjdk/jdk/blob/b9c6ce900b512adfcaccd2341be3eb0003a28b87/src/hotspot/share/opto/chaitin.cpp#L691 I was able to reproduce the issue reliably running test/hotspot/jtreg/applications/ctw/modules/java_desktop.java on ppc64le but not on x86_64. For that I replaced the ChunkPool with an allocator that mmaps Chunks to increasing addresses and unmaps when ResourceMarks are popped. The issue didn't reproduce without the ResourceMark in merge_multidefs. Sidemark: GrowableArrayNestingCheck does not fail because an Arena is explicitly passed to the GrowableArray constructor. https://github.com/openjdk/jdk/blob/b9c6ce900b512adfcaccd2341be3eb0003a28b87/src/hotspot/share/opto/chaitin.hpp#L378 even though it is the current thread's ResourceArea https://github.com/openjdk/jdk/blob/b9c6ce900b512adfcaccd2341be3eb0003a28b87/src/hotspot/share/opto/chaitin.cpp#L212 The nesting check is only performed if the GrowableArray allocates from the current thread's ResourceArea. The nesting check fails if the GrowableArray constructor for the ResourceArea is used. I think the nesting check can be generalized for arbitrary ResourceAreas (will create a RFE).
18-11-2024
> This happend today in our jdk21u-dev tests. Did we backport a bad change? The issue was observed before a few times in jdk21 (for example in September 2024 on Linux ppc64le, and in July 2024 on AIX) so it is not new. However it occurs more often in jdk24 (maybe because we run tests there more often, maybe because the coding is different in 24).
08-11-2024
This happend today in our jdk21u-dev tests. Did we backport a bad change? applications/ctw/modules/java_desktop.java linuxppc64le
08-11-2024
[~thartmann] have you maybe seen crashes with the badResourceValue pattern recently?
04-10-2024
The issue is mostly ( ~ 80% - 90% of cases) triggered by the applications/ctw/modules tests like applications/ctw/modules/java_management.java applications/ctw/modules/jdk_internal_le.java applications/ctw/modules/java_xml.java applications/ctw/modules/java_desktop.java Is there anything special in those tests, that they can trigger this assertion ? Additionally , 15 of the now 35 observations are since since 10th September (jdk24 , except 2 times jdk21) , so the issue shows up much more in recent weeks.
04-10-2024
Crash happens while accessing corrupted resource area storage "_lrg_map.live_range_id(n)" in https://github.com/openjdk/jdk/blob/6f459aff453679ee89fd80bb325737d76288e4d2/src/hotspot/share/opto/chaitin.cpp#L780 The crash has been observed 34 times. Mostly on PPC, but 2x on Windows x86_64. The first occurrence was on 2024-01-15.
03-10-2024
Since start of June 2024, we had 10 ocurrances of this issue, 2 on Windows x86_64, 4 on AIX, 4 on Linux ppc64le. applications/ctw/modules/java_desktop.java test seems to trigger it rather often (but not always). Last one on Linux ppc64le: # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-linux_ppc64le-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=25351, tid=25379 # assert(idx < _maxlrg) failed: oob: index 2880154539 not smaller than 840 Current thread (0x00007fff885cc490): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=25379, stack(0x00007fff59720000,0x00007fff59b20000) (4096K)] Current CompileTask: C2:78051 9416 b 4 com.sun.java.swing.plaf.gtk.GTKColorType::<clinit> (88 bytes) Stack: [0x00007fff59720000,0x00007fff59b20000], sp=0x00007fff59b1b0e0, free space=4076k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x838190] PhaseIFG::lrgs(unsigned int) const [clone .part.0]+0x50 (chaitin.hpp:295) V [libjvm.so+0x84d9d4] PhaseChaitin::lrgs(unsigned int) const+0x64 (chaitin.hpp:493) V [libjvm.so+0x84c930] PhaseChaitin::Register_Allocate()+0xc80 (chaitin.cpp:658) V [libjvm.so+0x9f8474] Compile::Code_Gen()+0x354 (compile.cpp:2966) V [libjvm.so+0x9fb3e0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a40 (compile.cpp:885) V [libjvm.so+0x7ae354] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c4 (c2compiler.cpp:142) V [libjvm.so+0xa0c564] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd34 (compileBroker.cpp:2303) V [libjvm.so+0xa0d218] CompileBroker::compiler_thread_loop()+0x608 (compileBroker.cpp:1961) V [libjvm.so+0xa349c4] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x54 (compilerThread.cpp:65) V [libjvm.so+0x102a990] JavaThread::thread_main_inner()+0x140 (javaThread.cpp:758) V [libjvm.so+0x1bce530] Thread::call_run()+0xe0 (thread.cpp:225) V [libjvm.so+0x16ca54c] thread_native_entry(Thread*)+0x18c (os_linux.cpp:858) C [libpthread.so.0+0xaa68] start_thread+0x108 Registers: pc =0x00007fff8d298190 lr =0x00007fff8d2ad9d4 ctr=0x00007fff8f4f7740 r0 =0x00007fff8d2ad9d4 r1 =0x00007fff59b1b0e0 r2 =0x00007fff8f100e00 r3 =0x00007fff8ea36798 r4 =0x0000000000000127 r5 =0x00007fff8ea36778 r6 =0x00007fff8ea36750 r7 =0x00000000abababab r8 =0x0000000000000058 r9 =0x00007fff59b1b2a0 r10=0x00007fff8f470000 r11=0x00007fff8e2b17c0 r12=0x00007fff8f4f7740 r13=0x00007fff59b268f0 r14=0x0000000000000003 r15=0x0000000000000010 r16=0x00007fff59b1b7d8 r17=0x00007fff8ea38700 r18=0x00007fff59b1b818 r19=0x00007fff59b1b260 r20=0x00007fff8ea38638 r21=0x00007fff59b1b6d0 r22=0x0000000000000001 r23=0x00007fff59b1b1f0 r24=0x00007fff59b1b268 r25=0x00007fff8f18f7b0 r26=0x0000000000000000 r27=0x000000000000001f r28=0x00007fff8f1819d0 r29=0x00007fff59b1b228 r30=0x00007fff59b1b6a8 r31=0x00007fff59b1b0e0
02-09-2024
We observed it today in jdk21 on AIX (fastdebug) in the test : applications/ctw/modules/jdk_internal_le.java # Internal Error (/priv/jenkins/client-home/workspace/openjdk-21u-dev-aix_ppc64-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=8519960, tid=3599 # assert(idx < _maxlrg) failed: oob: index 4294967295 not smaller than 228 Stack: [0x0000000113fb0000,0x00000001143ad788], sp=0x00000001143a9e00, free space=4071k No context given, using current context. Native frame: iar: 0x090000001bd328fc libjvm.so::AixNativeCallstack::print_callstack_for_context(outputStream*, ucontext_t const*, bool, char*, unsigned long)+0x4d4 (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:5 parmsonstk:1) lr: 0x090000001b3c59b4 libjvm.so::fdStream::write(char const*, unsigned long)+0x44 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:3 parmsonstk:1) sp: 0x00000001143a90c0 (base - 0x46C8) rtoc: 0x08001000a03e1790 |---stackaddr----| |----lrsave------|: <function name> 0x00000001143a94b0 - 0x090000001bd323b4 libjvm.so::os::Aix::platform_print_native_stack(outputStream*, void const*, char*, int, unsigned char*&)+0x24 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:5 parmsonstk:1) 0x00000001143a9530 - 0x090000001b3d2b14 libjvm.so::VMError::report(outputStream*, bool)+0x1b98 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:2 parmsonstk:1) 0x00000001143a9e10 - 0x090000001b3c4dc8 libjvm.so::VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x7cc (C++ uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:8 parmsonstk:1) 0x00000001143aa000 - 0x090000001b3c45b0 libjvm.so::VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:2 fixedparms:7 parmsonstk:1) 0x00000001143aa0a0 - 0x090000001b3c4290 libjvm.so::report_vm_error(char const*, int, char const*, char const*, ...)+0x8c (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:4 parmsonstk:1) 0x00000001143aa140 - 0x090000001c18298c libjvm.so::PhaseChaitin::Register_Allocate()+0x1040 (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x00000001143aa4e0 - 0x090000001c161c70 libjvm.so::Compile::Code_Gen()+0x22c (C++ uses_alloca saves_lr stores_bc gpr_saved:6 fixedparms:1 parmsonstk:1) 0x00000001143ab120 - 0x090000001c1e0760 libjvm.so::Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x17fc (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x00000001143abd90 - 0x090000001c3f0f64 libjvm.so::C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1e0 (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x00000001143ac990 - 0x090000001b7013d0 libjvm.so::CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcf4 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x00000001143ad110 - 0x090000001b6f1ad0 libjvm.so::CompileBroker::compiler_thread_loop()+0x3f0 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 parmsonstk:1) 0x00000001143ad360 - 0x090000001b6f1660 libjvm.so::CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:2 parmsonstk:1) 0x00000001143ad3e0 - 0x090000001b597140 libjvm.so::JavaThread::thread_main_inner()+0x1f8 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:1 parmsonstk:1) 0x00000001143ad4b0 - 0x090000001b595284 libjvm.so::JavaThread::run()+0x21c (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:1 parmsonstk:1) 0x00000001143ad550 - 0x090000001b4c24c8 libjvm.so::Thread::call_run()+0x128 (C++ uses_alloca saves_lr stores_bc gpr_saved:3 fixedparms:1 parmsonstk:1) 0x00000001143ad5e0 - 0x090000001b4c19f8 libjvm.so::thread_native_entry(Thread*)+0x194 (C++ uses_alloca saves_lr stores_bc gpr_saved:9 fixedparms:1 parmsonstk:1) 0x00000001143ad6a0 - 0x0900000000089214 libpthreads.a::<nameless function>+? (ASM tocless )
30-07-2024
Hi [~thartmann] we observed it recently also on Windows x64 (fastdebug binaries). So it seems that this occurs only more often on the ppc platforms. # Internal Error (c:\workspace\openjdk-jdk-dev-windows_x86_64-dbg\jdk\src\hotspot\share\opto/chaitin.hpp:295), pid=9308, tid=39600 # assert(idx < _maxlrg) failed: oob: index 963 not smaller than 806 Current CompileTask: C2:62348 8445 4 java.util.TimSort::binarySort (223 bytes) Stack: [0x000000be50800000,0x000000be50900000] Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xc9ae31] os::win32::platform_print_native_stack+0x101 (os_windows_x86.cpp:235) V [jvm.dll+0x10136d1] VMError::report+0x1491 (vmError.cpp:1011) V [jvm.dll+0x1015c33] VMError::report_and_die+0x633 (vmError.cpp:1846) V [jvm.dll+0x1016334] VMError::report_and_die+0x64 (vmError.cpp:1611) V [jvm.dll+0x5616ab] report_vm_error+0x5b (debug.cpp:193) V [jvm.dll+0x78b734] PhaseChaitin::compute_initial_block_pressure+0x274 (ifg.cpp:533) V [jvm.dll+0x7897d8] PhaseChaitin::build_ifg_physical+0x298 (ifg.cpp:872) V [jvm.dll+0x430068] PhaseChaitin::Register_Allocate+0x7e8 (chaitin.cpp:578) V [jvm.dll+0x4eb13f] Compile::Code_Gen+0x25f (compile.cpp:2968) V [jvm.dll+0x4e9c2b] Compile::Compile+0x12cb (compile.cpp:886) V [jvm.dll+0x3f645e] C2Compiler::compile_method+0x17e (c2compiler.cpp:145) V [jvm.dll+0x5066ef] CompileBroker::invoke_compiler_on_method+0x92f (compileBroker.cpp:2306) V [jvm.dll+0x503d21] CompileBroker::compiler_thread_loop+0x391 (compileBroker.cpp:1962) V [jvm.dll+0x8088c9] JavaThread::thread_main_inner+0x279 (javaThread.cpp:760) V [jvm.dll+0xf74938] Thread::call_run+0x1c8 (thread.cpp:230) V [jvm.dll+0xc99476] thread_native_entry+0xd6 (os_windows.cpp:553) C [ucrtbase.dll+0x2268a] (no source info available) C [KERNEL32.DLL+0x17ac4] (no source info available) C [ntdll.dll+0x5a4e1] (no source info available)
21-06-2024
One more from AIX (jdk24) , test triggering the issue was applications/ctw/modules/java_desktop.java : ------------------------------------------------------------------------------------------------------------------------------------------------ # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=11731392, tid=3599 # assert(idx < _maxlrg) failed: oob: index 2880154539 not smaller than 845 # --------------- T H R E A D --------------- Current thread (0x00000001153aa0b0): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=3599, stack(0x00000001153b0000,0x00000001157ad888) (4086K)] Current CompileTask: C2:68639 9517 b 4 com.sun.java.swing.plaf.gtk.GTKColorType::<clinit> (88 bytes) Stack: [0x00000001153b0000,0x00000001157ad888], sp=0x00000001157a9d60, free space=4071k No context given, using current context. Native frame: iar: 0x090000001e07116c libjvm.so::AixNativeCallstack::print_callstack_for_context(outputStream*, ucontext_t const*, bool, char*, unsigned long)+0x4cc (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:5 parmsonstk:1) lr: 0x090000001ddf1bec libjvm.so::fdStream::write(char const*, unsigned long)+0x44 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:3 parmsonstk:1) sp: 0x00000001157a9020 (base - 0x4868) rtoc: 0x08001000a03d8290 |---stackaddr----| |----lrsave------|: <function name> 0x00000001157a9410 - 0x090000001e070c2c libjvm.so::os::Aix::platform_print_native_stack(outputStream*, void const*, char*, int, unsigned char*&)+0x24 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:5 parmsonstk:1) 0x00000001157a9490 - 0x090000001de063cc libjvm.so::VMError::report(outputStream*, bool)+0x1c0c (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:2 parmsonstk:1) 0x00000001157a9d70 - 0x090000001ddf0eb0 libjvm.so::VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x72c (C++ uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:8 parmsonstk:1) 0x00000001157a9f80 - 0x090000001ddf0738 libjvm.so::VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, char*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:2 fixedparms:7 parmsonstk:1) 0x00000001157aa020 - 0x090000001ddf0418 libjvm.so::report_vm_error(char const*, int, char const*, char const*, ...)+0x8c (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:4 parmsonstk:1) 0x00000001157aa0c0 - 0x090000001eb9d4c4 libjvm.so::PhaseChaitin::Register_Allocate()+0x10a8 (C++ fp_present uses_alloca saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x00000001157aa470 - 0x090000001eb7c880 libjvm.so::Compile::Code_Gen()+0x22c (C++ uses_alloca saves_lr stores_bc gpr_saved:6 fixedparms:1 parmsonstk:1) 0x00000001157ab0b0 - 0x090000001ebfa9a0 libjvm.so::Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x169c (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x00000001157abd30 - 0x090000001ee1ae84 libjvm.so::C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x25c (C++ uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:6 parmsonstk:1) 0x00000001157aca70 - 0x090000001e14f0bc libjvm.so::CompileBroker::invoke_compiler_on_method(CompileTask*)+0xcf4 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 fixedparms:1 parmsonstk:1) 0x00000001157ad200 - 0x090000001e123d00 libjvm.so::CompileBroker::compiler_thread_loop()+0x4c0 (C++ fp_present uses_alloca saves_cr saves_lr stores_bc gpr_saved:18 parmsonstk:1) 0x00000001157ad450 - 0x090000001e1237c0 libjvm.so::CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x58 (C++ uses_alloca saves_lr stores_bc gpr_saved:1 fixedparms:2 parmsonstk:1) 0x00000001157ad4d0 - 0x090000001e061fc4 libjvm.so::JavaThread::thread_main_inner()+0x1f8 (C++ uses_alloca saves_lr stores_bc gpr_saved:4 fixedparms:1 parmsonstk:1) 0x00000001157ad5a0 - 0x090000001e06009c libjvm.so::JavaThread::run()+0x214 (C++ uses_alloca saves_lr stores_bc gpr_saved:5 fixedparms:1 parmsonstk:1) 0x00000001157ad640 - 0x090000001df0e804 libjvm.so::Thread::call_run()+0x128 (C++ uses_alloca saves_lr stores_bc gpr_saved:3 fixedparms:1 parmsonstk:1) 0x00000001157ad6d0 - 0x090000001df0dd64 libjvm.so::thread_native_entry(Thread*)+0x214 (C++ uses_alloca saves_lr stores_bc gpr_saved:10 fixedparms:1 parmsonstk:1) 0x00000001157ad7a0 - 0x090000000056204c libpthreads.a::_pthread_body+0xec (C saves_lr stores_bc gpr_saved:1 fixedparms:1 ) 0x00000001157ad820 - 0x0000000000000000 *** end of backchain *** -----------------------
18-06-2024
Enhancing the assertion (JDK-8328165) showed that idx == 0xFFFFFFFF or 0xABABABAB have occurred. Problem has been observed for the first time on 2024-01-15 in JDK22. Occurrences in these tests: vmTestbase/vm/mlvm/indy/func/java/verifyStackTrace/INDIFY_Test.java vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java applications/ctw/modules/java_desktop.java applications/ctw/modules/jdk_internal_le.java tools/javac/varargs/warning/Warn4.java Only on PPC64 so far, but that may possibly be a coincidence.
20-05-2024
2 more times the issue occurred but this time on Linux ppc64le : test vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java (jdk22u) # Internal Error (/priv/jenkins/client-home/workspace/openjdk-22u-linux_ppc64le-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=2383725, tid=3241070 # assert(idx < _maxlrg) failed: oob Current CompileTask: C2:943922 9557 4 com.sun.tools.javac.comp.Check::checkMethod (555 bytes) Stack: [0x00007fff52600000,0x00007fff52a00000], sp=0x00007fff529fb080, free space=4076k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x8730cc] PhaseIFG::lrgs(unsigned int) const+0x7c (chaitin.hpp:295) V [libjvm.so+0x871d70] PhaseChaitin::Register_Allocate()+0xc80 (chaitin.hpp:493) V [libjvm.so+0xa1f5e4] Compile::Code_Gen()+0x354 (compile.cpp:2969) V [libjvm.so+0xa2215c] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a8c (compile.cpp:890) V [libjvm.so+0x7d07d8] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1e8 (c2compiler.cpp:134) V [libjvm.so+0xa331a4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd34 (compileBroker.cpp:2305) V [libjvm.so+0xa33ed8] CompileBroker::compiler_thread_loop()+0x6a8 (compileBroker.cpp:1964) V [libjvm.so+0xa61b64] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x54 (compilerThread.cpp:68) V [libjvm.so+0x10684ac] JavaThread::thread_main_inner()+0x14c (javaThread.cpp:721) V [libjvm.so+0x1bc14b0] Thread::call_run()+0xe0 (thread.cpp:221) V [libjvm.so+0x16e178c] thread_native_entry(Thread*)+0x18c (os_linux.cpp:814) C [libc.so.6+0xaa130] start_thread+0x170 test vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java (jdk23) # Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-linux_ppc64le-dbg/jdk/src/hotspot/share/opto/chaitin.hpp:295), pid=32524, tid=43244 # assert(idx < _maxlrg) failed: oob Current CompileTask: C2:969585 8971 4 com.sun.tools.javac.comp.Check::checkMethod (555 bytes) Stack: [0x00007ffedcac0000,0x00007ffedcec0000], sp=0x00007ffedcebb120, free space=4076k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x86c01c] PhaseIFG::lrgs(unsigned int) const+0x7c (chaitin.hpp:295) V [libjvm.so+0x86acc0] PhaseChaitin::Register_Allocate()+0xc80 (chaitin.hpp:493) V [libjvm.so+0xa1bc14] Compile::Code_Gen()+0x354 (compile.cpp:2984) V [libjvm.so+0xa1e820] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1a80 (compile.cpp:894) V [libjvm.so+0x7d4434] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c4 (c2compiler.cpp:142) V [libjvm.so+0xa2fb24] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd44 (compileBroker.cpp:2310) V [libjvm.so+0xa30878] CompileBroker::compiler_thread_loop()+0x6a8 (compileBroker.cpp:1969) V [libjvm.so+0xa5d1e4] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x54 (compilerThread.cpp:68) V [libjvm.so+0x1065f3c] JavaThread::thread_main_inner()+0x14c (javaThread.cpp:721) V [libjvm.so+0x1bd0f70] Thread::call_run()+0xe0 (thread.cpp:221) V [libjvm.so+0x16e898c] thread_native_entry(Thread*)+0x18c (os_linux.cpp:864) C [libpthread.so.0+0x9748] start_thread+0xf8
15-03-2024
Hi [~thartmann] we are not sure if this is really ppc64-only / oraclejdk-na . Could be that it is just more likely to occur on this platform. Btw. we only saw it on AIX (big endian ppc64), so far never on ppc64 little endian .
14-03-2024