[maccatalyst][CoreCLR] Fault while logging the fatal-error call stack spins in PAL_DispatchException instead of terminating

[lewing]

Description

When a managed crash hits CoreCLR's fatal-error path on maccatalyst-arm64, logging the managed call stack can fault a second time inside the signal handler. The process then spins in PAL_DispatchException indefinitely instead of terminating. In CI this turns a crash into a hang that is only killed by the XHarness timeout (75 minutes), with no crash report and TEST_RESULTS_MISSING.

How it was found

The first fault was a real bug, fixed in #134699: an interpreted delegate shuffle thunk called CID_VirtualOpenDelegateDispatch through calli without x11 set, so CID_VirtualOpenDelegateDispatchWorker read a garbage delegate. This issue is about what happened after that fault.

Reproduced locally on maccatalyst-arm64 CoreCLR Release (macOS 26.6.2, Apple M5 Max) with System.Runtime.Tests at commit 9665c7d75e0, before the #134699 fix. CI occurrence: build 1613389, maccatalyst-arm64 Release AllSubsets_CoreCLR_Smoke, Helix job 5f296c2d-4f02-462f-ad48-7ae9c68579d8, work item System.Runtime.Tests ("Run timed out after 4500 seconds").

Stack (sample of the hung process, crashing thread)

CID_VirtualOpenDelegateDispatch
CID_VirtualOpenDelegateDispatchWorker          <- first fault
_sigtramp
invoke_previous_action(sigaction*, int, __siginfo*, void*, bool)
EEPolicy::LogManagedCallstackForSignal(char16_t const*)
LogInfoForFatalError(...)
LogCallstackForLogWorker(Thread*, _EXCEPTION_POINTERS*, bool)
CallStackLogger::PrintStackTrace(char16_t const*, unsigned long long)
CallStackLogger::PrintFrame(int, char16_t const*, unsigned int, unsigned int)
TypeString::AppendMethodInternal(SString&, MethodDesc*, unsigned int)
TypeString::AppendMethodImpl(SString&, MethodDesc*, Instantiation, unsigned int)   <- second fault
PAL_DispatchExceptionWrapper
PAL_DispatchException
  302/328 samples: cthread_yield -> swtch_pri
   26/328 samples: MachMessage::SendForwardException -> thread_self_trap

Across the whole sample, this thread's hottest top-of-stack frames were TypeString::AppendMethodImpl (1332) and PAL_DispatchException (159).

Expected behavior

A fault while logging the fatal-error call stack should not prevent termination. The process should abort, possibly with a truncated stack log, so the harness reports a crash promptly.

Other information

• It is not yet known which frame supplied the invalid MethodDesc. A likely candidate is the StubDispatchFrame pushed by CID_VirtualOpenDelegateDispatchWorker before it faulted.
• Once the first fault is fixed by [interpreter] Resolve open virtual delegates invoked through the shuffle thunk (wasm, Apple mobile) #134699, this path is no longer reachable from that test, but any similar fault can still turn into a hang.

Note

This issue was generated with GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'os-maccatalyst': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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