Bug ID: JDK-8343938 TestStressBailout triggers "Should not be locked when freed" assert

Versions (Unresolved/Resolved/Fixed)

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
25 b08Fixed

# 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

Changeset: fff97d6d Branch: master Author: Theo Weidmann <tweidmann@openjdk.org> Committer: Tobias Hartmann <thartmann@openjdk.org> Date: 2025-01-29 08:59:19 +0000 URL: https://git.openjdk.org/jdk/commit/fff97d6d9ae136121f042c760fed2ece431f9473
29-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23195 Date: 2025-01-20 09:45:05 +0000
21-01-2025
This is a race condition where CompileQueue::free_all notifies on the lock of a Task t (line 372) and then calls CompileTask::free for the task t, which assumes t's lock is unlocked. However, if CompileBroker::wait_for_completion is currently waiting on t's lock on another thread that thread might wake up and lock the lock before free completes, triggering the assert. Applying the attached diff and running -Xcomp -XX:-TieredCompilation -XX:+StressBailout -XX:StressBailoutMean=2 -Xbatch --version reliably reproduced the issue.
15-01-2025
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

Relates :	JDK-8330157 - C2: Add a stress flag for bailouts
Relates :	JDK-8361752 - Double free in CompileQueue::delete_all after JDK-8357473