[Apple][CoreCLR] GC suspension never completes in b425314: runtime can't suspend a tight R2R loop

[lewing]

Description

On CoreCLR maccatalyst-arm64 (Release, composite R2R), the runtime test JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b425314 (b425314.Mutate.TestEntryPoint, in the Regression_d merged runner) never finishes. It hung in two separate local runs, for 39 and 82 minutes, well past the test's own 180-second limit.

This only became visible after #134767, which makes Apple CoreCLR runtime-test lanes run tests at all (#134766). The same test passes on Android CoreCLR arm64 (emulator) with the equivalent fix.

Analysis (from sample of the hung process)

• Check thread (CastClass.CheckObjects): throws an expected InvalidCastException. Allocating the stack-trace array triggers a GC:

  StackTraceArray::Allocate -> Alloc -> gc_heap::trigger_gc_for_alloc -> GCHeap::GarbageCollectGeneration
  -> GCToEEInterface::SuspendEE -> ThreadSuspend::SuspendEE -> ThreadSuspend::SuspendAllThreads -> minipal_microdelay
  

  SuspendAllThreads never completes; it spins in minipal_microdelay.
• Flip thread is running R2R code in a tight loop (b425314.CastClass.Flip / ScenarioMonitor.RecordFlipIteration in Regression_d.r2r.dylib) and never reaches a safe point.
• Timer thread (TimerQueue.TimerThread) is blocked in Thread::RareDisablePreemptiveGC waiting for the GC. So the test's 180-second maximum-time timer can never fire, and the process hangs instead of failing.

FEATURE_HIJACK and the activation signal (INJECT_ACTIVATION_SIGNAL) are compiled in for Apple, so it isn't yet clear why the flip thread can't be interrupted there. Loops in R2R code without GC polls that can't be hijacked or activated on Apple mobile would explain it. That is a hypothesis; I haven't checked it.

Repro

1. Build clr+clr.runtime+libs+packs -os maccatalyst -arch arm64 -c Release /p:UseMonoRuntime=false /p:UseNativeAOTRuntime=false /p:DevTeamProvisioning=adhoc with [Apple][Android][CoreCLR] Don't pass the program path as managed args[0]; quarantine newly running runtime tests #134767 applied.
2. src/tests/build.sh -os maccatalyst arm64 Release -p:DevTeamProvisioning=adhoc -p:UseMonoRuntime=false -p:UseNativeAOTRuntime=false -test:JIT/Regression/Regression_d.csproj
3. Run the app with xharness apple test --target maccatalyst.

iOS and tvOS were not run locally. They use the same CoreCLR Apple runtime and are expected to behave the same.

Quarantine

#134767 disables b425314.Mutate.TestEntryPoint with ActiveIssue when both IsAppleMobile and IsCoreCLR are true. Re-enable once runtime suspension of that loop completes on Apple mobile.

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 'os-tvos': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @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.

[lewing]

b426654 (JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b426654, work item Regression_1) hangs the same way on maccatalyst CoreCLR, and #134767 quarantines it against this issue as well.

Note

This comment was generated with GitHub Copilot.

[vitek-karas]

@BrzVlad can you please look into this? We need to triage if this is important to fix in soon (try to get it to 11) or it can wait for 12/servicing.