After applying JDK-8364501 changes to leyden repo I hit the assert.

I think the same issue exist in mainline (and filing bug here).

The task which failed is "stale task". And CompileQueue::purge_stale_tasks() misses `task->set_next(nullptr)`.
The field task->_prev is fine: it is set to nullptr in CompileQueue::remove_and_mark_stale()'.

It mainline it is very rare case. In leyden it is amplified by UseLockFreeCompileQueues code (may be there is bug there which marks more compilation tasks as "stale").

$ make test CONF=fast TEST=compiler/c1/TestConcurrentPatching.java

# Internal Error (/workspace/open/src/hotspot/share/compiler/compileBroker.cpp:1974), pid=53131, tid=53248
# assert(task->next() == nullptr && task->prev() == nullptr) failed: Completed task should not be in the queue
#
# JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-internal-2025-08-20-2238345.leyden)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-internal-2025-08-20-2238345.leyden, compiled mode, emulated-client, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0xba5a32] CompileBroker::wait_for_completion(CompileTask*)+0x2e2
#

Flags: -Xcomp -XX:CompileCommand=compileonly,TestConcurrentPatching::* -XX:TieredStopAtLevel=1

V [libjvm.so+0xba5a32] CompileBroker::wait_for_completion(CompileTask*)+0x2e2 (compileBroker.cpp:1974)
V [libjvm.so+0xbad7f8] CompileBroker::compile_method(methodHandle const&, int, int, int, bool, CompileTask::CompileReason, DirectiveSet*, JavaThread*)+0x4f8 (compileBroker.cpp:1690)
V [libjvm.so+0xbadeac] CompileBroker::compile_method(methodHandle const&, int, int, int, bool, CompileTask::CompileReason, JavaThread*)+0xbc (compileBroker.cpp:1573)
V [libjvm.so+0xb6e2b9] CompilationPolicy::compile_if_required(methodHandle const&, JavaThread*)+0xc9 (compilationPolicy.cpp:175)