JDK-8343938 : TestStressBailout triggers "Should not be locked when freed" assert
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 24,25
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-11-11
  • Updated: 2024-11-11
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 25
25Unresolved
Related Reports
Relates :  
JDK-8330157 - C2: Add a stress flag for bailouts
Description
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/compiler/compileTask.cpp:68), pid=2387845, tid=2387871
#  assert(!task->lock()->is_locked()) failed: Should not be locked when freed
#
# JRE version: Java(TM) SE Runtime Environment (24.0+24) (fastdebug build 24-ea+24-2869)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+24-2869, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x8f04c4]  CompileTask::free(CompileTask*)+0xe4

Stack: [0x0000ffff77a04000,0x0000ffff77c02000],  sp=0x0000ffff77c000e0,  free space=2032k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8f04c4]  CompileTask::free(CompileTask*)+0xe4  (compileTask.cpp:68)
V  [libjvm.so+0x8e1f20]  CompileQueue::free_all()+0x70  (compileBroker.cpp:375)
V  [libjvm.so+0x8e43c4]  CompileBroker::shutdown_compiler_runtime(AbstractCompiler*, CompilerThread*)+0xb4  (compileBroker.cpp:1840)
V  [libjvm.so+0x8e487c]  CompileBroker::init_compiler_runtime()+0x438  (compileBroker.cpp:1794)
V  [libjvm.so+0x8eadd4]  CompileBroker::compiler_thread_loop()+0x114  (compileBroker.cpp:1929)
V  [libjvm.so+0xd4cc58]  JavaThread::thread_main_inner()+0xe4  (javaThread.cpp:758)
V  [libjvm.so+0x15dd4e0]  Thread::call_run()+0xac  (thread.cpp:232)
V  [libjvm.so+0x1317774]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:858)
C  [libpthread.so.0+0x7950]  start_thread+0x190

Test was added by JDK-8330157
Comments
Assuming that this is an old issue that only reproduces intermittently now in our CI due to -XX:+StressBailout, I target this to JDK 25. Feel free to re-target if this assumption turns out incorrect. ILW = Assert because CompileTask is locked when freed (potential memory corruption but never observed), intermittent with stress option, no workaround but avoid shutdown of compiler runtime = HLM = P3
11-11-2024
I think the -XX:+StressBailout flag triggers a bailout during generation of runtime stubs via C2Compiler::init_c2_runtime -> OptoRuntime::generate which then leads to CompileBroker::shutdown_compiler_runtime which probably triggers an existing bug. Looking at the assert in CompileTask::free I wonder what prevents another thread from holding the lock.
11-11-2024