PerfMap / CodeFragmentHeap lock-ordering deadlock during GC suspension

[leculver]

Description

A .NET 10 process on Linux can hang permanently when the DOTNET_PerfMapEnabled code path is active (env var or runtime-enabled via the Diagnostics Server IPC, e.g. dotnet-trace --enable-perfmap). The hang is a three-way deadlock between the GC suspension machinery, CodeFragmentHeap::m_Lock, and PerfMap::s_csPerfMap, triggered while a virtual-call-stub resolve worker is generating a new resolve stub.

The two locks are taken in the wrong order with respect to GC-mode handling:

• CodeFragmentHeap::m_Lock is constructed with CRST_UNSAFE_ANYMODE, so acquiring it does not toggle the calling thread to preemptive GC.
• PerfMap::s_csPerfMap is constructed with CRST_DEFAULT (no flags), so acquiring it does toggle a cooperative thread to preemptive via Thread::RareDisablePreemptiveGC, which can block while a GC suspension is in progress.

The result: a cooperative thread holding m_Lock calls into PerfMap, gets stuck inside RareDisablePreemptiveGC waiting for the GC to finish — but the GC is waiting for that same thread to reach a safe point, and every other thread that needs to allocate a stub is queued behind the held m_Lock.

Reproduction Steps

Likely synthetic repro recipe:

1. Run any .NET 10 Linux x64 workload with PerfMap enabled (DOTNET_PerfMapEnabled=1, or attach with dotnet-trace collect -p <pid> --enable-perfmap).
2. Drive heavy virtual-call-stub creation (large numbers of polymorphic interface call sites being warmed up concurrently) while also driving allocation that forces frequent GCs.
3. Eventually a cooperative thread is suspended inside PerfMap::LogStubs -> s_csPerfMap while holding CodeFragmentHeap::m_Lock, and the process deadlocks.

Crash dumps available to debug this directly though.

Expected behavior

PerfMap logging on a stub-allocation path must not be able to deadlock with the GC.

Not sure the actual fix, as CodeFragmentHeap::m_Lock was correctly "default" leaving us in coop mode because this was meant as a quick call, and the work behind PerfMap::s_csPerfMap is heavyweight, meaning we should let the GC run. This change makes ResolveWorkerAsmStub a more heavyweight function which may need to swap to preemptive mode, or possibly the calls into PerfMap need to be lighter weight. Or maybe I'm overthinking it.

Actual behavior

The GC thread is suspending the world and waiting on a cooperative thread to reach a safe point.

Thread 60 is preemptive, was about to acquire s_csPerfMap from inside PerfMap::LogStubs. The default-flagged Crst is toggling it to preemptive via RareDisablePreemptiveGC, where it now sits indefinitely because the GC is already trying to suspend it:

02  libcoreclr!GCEvent::Impl::Wait+0xd2                 unix/events.cpp:179
03  libcoreclr!Thread::RareDisablePreemptiveGC+0x14e    threadsuspend.cpp:2223
04  libcoreclr!CrstBase::AcquireLock+0xc                crst.h:174
05  libcoreclr!CrstBase::CrstHolder::CrstHolder+0xc     crosscomp.h:349
06  libcoreclr!PerfMap::LogStubs+0x19a                  perfmap.cpp:462
07  libcoreclr!CodeFragmentHeap::RealAllocAlignedMem+0x122
08  libcoreclr!VirtualCallStubManager::GenerateResolveStub+0xb6
09  libcoreclr!VirtualCallStubManager::ResolveWorker+0x8a8
0a  libcoreclr!VSD_ResolveWorker+0x2e7
0b  libcoreclr!ResolveWorkerAsmStub+0x71

Thread 60 is still holding CodeFragmentHeap::m_Lock from frame 07.

Thread 61 is cooperative, blocked at trying to acquire m_Lock (held by thread 60):

00  libc_so!__lll_lock_wait_private+0x90
01  libc_so!pthread_mutex_lock+0x167
02  libcoreclr!CrstBase::Enter+0x94                     crst.cpp:265
03  libcoreclr!CrstBase::AcquireLock+0x5                crst.h:174
04  libcoreclr!CrstBase::CrstHolder::CrstHolder+0x5     crosscomp.h:349
05  libcoreclr!CodeFragmentHeap::RealAllocAlignedMem+0x2a
06  libcoreclr!VirtualCallStubManager::GenerateResolveStub+0xb6
07  libcoreclr!VirtualCallStubManager::ResolveWorker+0x8a8
08  libcoreclr!VSD_ResolveWorker+0x2e7
09  libcoreclr!ResolveWorkerAsmStub+0x71

Because thread 61 is Cooperative and the GC is trying to suspend the runtime, the GC thread also waits on this thread to either reach a safe point or go preemptive — which it cannot do because it is parked inside pthread_mutex_lock.

Cycle:

GC  -> waits for cooperative threads to suspend
T60 -> preemptive, in RareDisablePreemptiveGC waiting for GC to finish
       (holds CodeFragmentHeap::m_Lock)
T61 -> cooperative, blocked on CodeFragmentHeap::m_Lock held by T60
       (and the GC is waiting on T61 to suspend)

Regression?

Likely a regression from #113943.

Known Workarounds

Two environment knobs that, set together, prevent the bad path from being exercised:

DOTNET_EnableDiagnostics_IPC=0
DOTNET_PerfMapEnabled=0

• DOTNET_PerfMapEnabled=0 ensures PerfMap::s_enabled stays false at startup, so PerfMap::LogStubs early-outs and never touches s_csPerfMap.
• DOTNET_EnableDiagnostics_IPC=0 shuts off the Diagnostics Server, which is otherwise able to enable PerfMap at runtime via the ds_rt_enable_perfmap IPC handler regardless of the env var (dotnet-trace --enable-perfmap, dotnet-monitor, third-party APM agents).

Both are needed: setting only one leaves the other path open.

Configuration

Likely not Linux specific, but that's where I debugged it.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[leculver]

Here's some additional places that need to be audited. This was done via AI, so take it with a grain of salt. Needs to be investigated, but the details below might be wildly wrong.

ExecutionManager::getNextJumpStub

Acquires m_JumpStubCrst (CRST_UNSAFE_ANYMODE | CRST_DEBUGGER_THREAD), then later calls PerfMap::LogStubs directly. The whole function body runs under that lock per the precondition.

• m_JumpStubCrst init (CRST_UNSAFE_ANYMODE): codeman.cpp:5227
• Lock acquired by caller (getJumpStub) before invoking getNextJumpStub: codeman.cpp:5895, codeman.cpp:5938
• getNextJumpStub definition + lock precondition: codeman.cpp:5953-5962
• PerfMap::LogStubs call: codeman.cpp:6067

EEJitManager::AllocJumpStubBlock

AllocJumpStubBlock is itself called from getNextJumpStub while m_JumpStubCrst is held. The inner m_CodeHeapLock is released before ReportStubBlock, but the outer m_JumpStubCrst is still held, so ReportStubBlock (-> PerfMap::LogStubs) acquires the toggling lock from a cooperative thread I think.

• m_CodeHeapLock definition (CRST_UNSAFE_ANYMODE, also no-toggle): codeman.cpp:1249-1250
• AllocJumpStubBlock: codeman.cpp:3311
• Inner CrstHolder ch(&m_CodeHeapLock) scope: codeman.cpp:3339-3358
• ReportStubBlock call (outside inner scope but inside outer m_JumpStubCrst): codeman.cpp:3360

LoaderAllocator::AddRangeWorkerHelper under LoaderHeap::m_CriticalSection

ReportStubBlock is called from AddRangeWorkerHelper, which itself is invoked from inside UnlockedAllocAlignedMem while the enclosing LoaderHeap is holding its own m_CriticalSection (a raw CRITICAL_SECTION via CRITSEC_Holder, not a Crst). A raw critical section does not participate in GC-mode toggling at all, equivalent to no-toggle from the runtime's perspective, so a cooperative thread can be parked inside RareDisablePreemptiveGC while still holding it. Triggered every time a LoaderHeap commits new pages (class loading, MethodDesc allocation, reflection-emit, etc.).

• LoaderAllocator::AddRangeWorkerHelper body: loaderallocator.hpp:85-108
• ReportStubBlock call (before taking _RangeListRWLock, but caller still holds m_CriticalSection): loaderallocator.hpp:87
• LoaderHeap::RealAllocAlignedMem acquires m_CriticalSection then calls UnlockedAllocAlignedMem: loaderheap.h:913-920
• UnlockedLoaderHeap::CommitNewPages calls m_pRangeList->AddRange (→ AddRangeWorker → AddRangeWorkerHelper): loaderheap.cpp:251

Lower-risk sites at the introduced call but caller-dependent

These release any inner heap lock before calling PerfMap::LogStubs; whether they can deadlock depends on what outer locks the caller of these functions holds. Common callers are class-loader and method-desc construction paths under CrstClassInit / app-domain locks; that's a broader audit not done here.

• Precode::Allocate — FixupPrecode: precode.cpp:292 · ThisPtrRetBuf: precode.cpp:306 · StubPrecode / PInvokeImportPrecode: precode.cpp:319
• Precode::AllocateInterpreterPrecode: precode.cpp:257
• UMEntryThunk allocation via P/Invoke callback: dllimportcallback.cpp:297

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.

[hoyosjs]

Given PAL_PerfJitDump_LogMethod and the writes it does under s_csPerfMap, it doesn't feel great to do CRST_UNSAFE_ANYMODE since we can get arbitrary pause times with slow NFS writes. However writing to file in COOP is already happening since grabbing the lock is just a toggle. This is the cheapest thing to do now. Something better would be to write in preemptive or deferred writing. @noahfalk @mdh1418 - what do you think for this one? For now I'll kick something that switches the CRST and see what happens - preemtive switching also works from the perspective of us not holding managed objects in that range, but I haven't audited the callers.

[hoyosjs]

repro stacks. coop thread waiting for Fragment lock:

00007F74155CA520 00007F8C591B3046 libc.so.6!__pthread_mutex_lock@GLIBC_2.2.5 + 342 at nptl/pthread_mutex_lock.c:48
00007F74155CA540 00007F8C58FCA5E5 libcoreclr.so!minipal_mutex_enter + 5 at /__w/1/s/src/runtime/src/native/minipal/mutex.c:52
00007F74155CA540 00007F8C58CC0574 libcoreclr.so!CrstBase::Enter() + 148 at /__w/1/s/src/runtime/src/coreclr/vm/crst.cpp:265
00007F74155CA570 00007F8C58F530FA libcoreclr.so!CodeFragmentHeap::RealAllocAlignedMem(unsigned long, unsigned int) + 42 at /__w/1/s/src/runtime/src/coreclr/vm/crst.h:0
00007F74155CA570 00007F8C58F530F5 libcoreclr.so!CodeFragmentHeap::RealAllocAlignedMem(unsigned long, unsigned int) + 37 at /__w/1/s/src/runtime/src/coreclr/vm/crst.h:174
00007F74155CA570 00007F8C58F530F5 libcoreclr.so!CodeFragmentHeap::RealAllocAlignedMem(unsigned long, unsigned int) + 37 at /__w/1/s/src/runtime/src/coreclr/vm/crst.h:174
00007F74155CA5D0 00007F8C58D949F6 libcoreclr.so!VirtualCallStubManager::GenerateResolveStub(unsigned long, unsigned long, unsigned long) + 182 at /__w/1/s/src/runtime/src/coreclr/inc/loaderheap.h:82
00007F74155CA640 00007F8C58D94068 libcoreclr.so!VirtualCallStubManager::ResolveWorker(StubCallSite*, Object**, DispatchToken, StubCodeBlockKind) + 2216 at /__w/1/s/src/runtime/src/coreclr/vm/virtualcallstub.cpp:0
00007F74155CA7D0 00007F8C58D93377 libcoreclr.so!VSD_ResolveWorker + 743 at /__w/1/s/src/runtime/src/coreclr/vm/virtualcallstub.cpp:0
00007F74155CA868                  [StubDispatchFrame: 00007f74155ca868] IWorker7.Compute2()
00007F74155CA910 00007F8C58F508A1 libcoreclr.so!ResolveWorkerAsmStub + 113 at /__w/1/s/src/runtime/src/coreclr/vm/amd64/virtualcallstubamd64.S:41
00007F74155CAA00 00007F8BDB700ECE System.Private.CoreLib.dll!DynamicClass.InvokeStub_IWorker7.Compute2(System.Object, System.Object, IntPtr*) + 46
00007F74155CAA20 00007F8BD9C6F07A System.Private.CoreLib.dll!System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(System.Object, System.Reflection.BindingFlags) + 74 [/_/src/runtime/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs @ 57]
00007F74155CAA50 00007F8BD9C8216A System.Private.CoreLib.dll!System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo) + 170 [/_/src/runtime/src/libraries/System.Private.CoreLib/src/System/Reflection/RuntimeMethodInfo.cs @ 126]
00007F74155CAAC0 00007F8BDA9E56D1 repro.dll!Program.<<Main>$>g__DoDispatch|0_0(System.Object, System.Reflection.MethodInfo, System.Object[]) + 33 [/home/hoyosjs/mocks/repro-128401/Program.cs @ 129]
00007F74155CAAD0 00007F8BDA9E55CA repro.dll!Program+<>c__DisplayClass0_1.<<Main>$>b__4() + 234 [/home/hoyosjs/mocks/repro-128401/Program.cs @ 83]
00007F74155CAB20 00007F8BD9BE9B16 System.Private.CoreLib.dll!System.Threading.Thread.StartCallback() + 134
00007F74155CACC0                  [DebuggerU2MCatchHandlerFrame: 00007f74155cacc0]

Fragment owning thread (and also s_csPerfMap) trying to toggle gc state:

(lldb) bt
* thread #15, stop reason = signal 0
  * frame #0: 0x00007f8c591ac117 libc.so.6`__GI___futex_abstimed_wait_cancelable64 [inlined] __futex_abstimed_wait_common64(private=<unavailable>, cancel=true, abstime=0x0000000000000000, op=393, expected=0, futex_word=0x00005598c6836c08) at futex-internal.c:57:12
    frame #1: 0x00007f8c591ac0e9 libc.so.6`__GI___futex_abstimed_wait_cancelable64 [inlined] __futex_abstimed_wait_common(cancel=true, private=<unavailable>, abstime=0x0000000000000000, clockid=<unavailable>, expected=0, futex_word=0x00005598c6836c08) at futex-internal.c:87:9
    frame #2: 0x00007f8c591ac0e9 libc.so.6`__GI___futex_abstimed_wait_cancelable64(futex_word=0x00005598c6836c08, expected=0, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>) at futex-internal.c:139:10
    frame #3: 0x00007f8c591aea41 libc.so.6`___pthread_cond_wait [inlined] __pthread_cond_wait_common(abstime=0x0000000000000000, clockid=0, mutex=0x00005598c6836c10, cond=0x00005598c6836be0) at pthread_cond_wait.c:503:10
    frame #4: 0x00007f8c591ae970 libc.so.6`___pthread_cond_wait(cond=0x00005598c6836be0, mutex=0x00005598c6836c10) at pthread_cond_wait.c:627:10
    frame #5: 0x00007f8c58c42902 libcoreclr.so`GCEvent::Impl::Wait(this=0x00005598c6836be0, milliseconds=<unavailable>, alertable=<unavailable>) at events.cpp:149:22 [opt]
    frame #6: 0x00007f8c58e69e8e libcoreclr.so`Thread::RareDisablePreemptiveGC(this=0x00005598c6e242a0) at threadsuspend.cpp:2222:58 [opt]
    frame #7: 0x00007f8c58d4510a libcoreclr.so`PerfMap::LogStubs(char const*, char const*, unsigned long, unsigned long, PerfMapStubType) [inlined] CrstBase::AcquireLock(c=<unavailable>) at crst.h:174:12 [opt]
    frame #8: 0x00007f8c58d450fe libcoreclr.so`PerfMap::LogStubs(char const*, char const*, unsigned long, unsigned long, PerfMapStubType) [inlined] CrstBase::CrstHolder::CrstHolder(this=<unavailable>, pCrst=<unavailable>) at crst.h:349:13 [opt]
    frame #9: 0x00007f8c58d450fe libcoreclr.so`PerfMap::LogStubs(stubType="ReportStubBlock", stubOwner="VSD_ResolveStub", pCode=140238645021504, codeSize=1024, stubAllocationType=Block) at perfmap.cpp:460:24 [opt]
    frame #10: 0x00007f8c58d45468 libcoreclr.so`ReportStubBlock(start=<unavailable>, size=<unavailable>, kind=<unavailable>) at perfmap.cpp:492:5 [opt] [artificial]
    frame #11: 0x00007f8c58f531f2 libcoreclr.so`CodeFragmentHeap::RealAllocAlignedMem(this=0x00005598c680a250, dwRequestedSize=<unavailable>, dwAlignment=16) at codeman.cpp:2107:9 [opt]
    frame #12: 0x00007f8c58d949f6 libcoreclr.so`VirtualCallStubManager::GenerateResolveStub(this=0x00005598c68099a0, addrOfResolver=140240764602608, addrOfPatcher=<unavailable>, dispatchToken=51539607554) at virtualcallstub.cpp:2997:23 [opt]
    frame #13: 0x00007f8c58d94068 libcoreclr.so`VirtualCallStubManager::ResolveWorker(this=0x00005598c68099a0, pCallSite=0x00007f74165cc858, protectedObj=0x00007f74165cc998, token=(m_token = 51539607554), stubKind=STUB_CODE_BLOCK_VSD_LOOKUP_STUB) at virtualcallstub.cpp:2050:46 [opt]
    frame #14: 0x00007f8c58d93377 libcoreclr.so`VSD_ResolveWorker(pTransitionBlock=<unavailable>, siteAddrForRegisterIndirect=<unavailable>, token=51539607554, flags=0) at virtualcallstub.cpp:1768:20 [opt]
    frame #15: 0x00007f8c58f508a1 libcoreclr.so`ResolveWorkerAsmStub at virtualcallstubamd64.S:39

Hit rate is low. Testing the modeany workaround