10.0.104 10.0.200 Regression with dotnet publish on macOS arm64 (exit code -11)

[RDI-Blake]

Describe the bug

During a dotnet publish, dotnet crashes with exit code -11 (SIGSEGV) on macOS arm64 using 10.0.104/10.0.200. I did not run into this issue with 10.0.103, even after downgrading.

To Reproduce

Run dotnet publish net10.0-ios MAUI on a project. Sometimes it does succeed, but most times fails. This is in a clean CI environment.

Further technical details

.NET itself does not throw an exception, but it crashes and generates a dotnet log in ~/Library/Logs/DiagnosticReports.

I've attached the macOS diagnostic report ips.

dotnet-2026-03-12-081456.json

[marcpopMSFT]

Routing to runtime as crashes of the dotnet process itself are typically from runtime bugs.

[dotnet-policy-service]

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

[agocke]

I think this is the crashing stack trace (obviously not all htat useful without symbol resolution):

FaultingThreadIndex: 27
ThreadId: 11878
Name: .NET TP Worker
Triggered: True

  at <image+0> [<unknown-image>]
  at _sigtramp+56 [libsystem_platform.dylib]
  at <image+4430789160> [<unknown-image>]
  at <image+4436032988> [<unknown-image>]
  at <image+4436029576> [<unknown-image>]
  at <image+4436034104> [<unknown-image>]
  at <image+4436171868> [<unknown-image>]
  at <image+4437159356> [<unknown-image>]
  at <image+4437366560> [<unknown-image>]
  at <image+4472683452> [<unknown-image>]
  at <image+4369123644> [<unknown-image>]
  at <image+4472683000> [<unknown-image>]
  at <image+4472682608> [<unknown-image>]
  at <image+4369315772> [<unknown-image>]
  at <image+4369283336> [<unknown-image>]
  at <image+4371449424> [<unknown-image>]
  at <image+4371512272> [<unknown-image>]
  at <image+4484886904> [<unknown-image>]
  at <image+4472671652> [<unknown-image>]
  at <image+4369123644> [<unknown-image>]
  at <image+4472671200> [<unknown-image>]
  at <image+4472670808> [<unknown-image>]
  at <image+4485578488> [<unknown-image>]
  at <image+4485622496> [<unknown-image>]
  at <image+4369186300> [<unknown-image>]
  at <image+4369243312> [<unknown-image>]
  at <image+4369064196> [<unknown-image>]
  at CallDescrWorkerInternal+132 [libcoreclr.dylib]
  at DispatchCallSimple(unsigned long*, unsigned int, unsigned long, unsigned int)+276 [libcoreclr.dylib]
  at KickOffThread_Worker(void*)+144 [libcoreclr.dylib]
  at ManagedThreadBase::KickOff(void (*)(void*), void*)+236 [libcoreclr.dylib]
  at KickOffThread(void*)+212 [libcoreclr.dylib]
  at CorUnix::CPalThread::ThreadEntry(void*)+352 [libcoreclr.dylib]
  at _pthread_start+136 [libsystem_pthread.dylib]
  at thread_start+8 [libsystem_pthread.dylib]

Total frames: 35

[steveisok]

Symbolicated the attached crash log using atos with debug symbols from the Microsoft.NETCore.App.Runtime.osx-arm64.symbols 10.0.4 NuGet package (UUID 567BD720-D4AD-3FF3-B39C-1982B66649E5 confirmed match).

Crashing thread (Thread 27, .NET TP Worker):

#00  libsystem_platform.dylib  _sigtramp+56
#01  libcoreclr.dylib          CallDescrWorkerInternal + 132
#02  libcoreclr.dylib          DispatchCallSimple(…)                    (callhelpers.cpp:239)
#03  libcoreclr.dylib          KickOffThread_Worker(void*)              (comsynchronizable.cpp)
#04  libcoreclr.dylib          ManagedThreadBase::KickOff(…)            (threads.cpp:7104)
#05  libcoreclr.dylib          KickOffThread(void*)                     (comsynchronizable.cpp:206)
#06  libcoreclr.dylib          CorUnix::CPalThread::ThreadEntry(void*)  (thread.cpp)

Thread 27 SIGSEGV'd in the CallDescrWorkerInternal assembly trampoline during managed thread startup — before any managed code executed.

GC context — neighboring TP worker threads (25, 26, 28) are all blocked in GC allocation:

Thread 25 (.NET TP Worker):
  #02  GCEvent::Impl::Wait(…)                                (events.cpp:179)
  #03  WKS::gc_heap::try_allocate_more_space(…)               (gc.cpp:19258)
  #07  RhpGcAlloc                                             (gchelpers.cpp)
  #08  RhpNewObject + 44

Thread 26 (.NET TP Worker):  [identical to Thread 25]

Thread 28 (.NET TP Worker):
  #02  GCEvent::Impl::Wait(…)                                (events.cpp:179)
  #03  Thread::RareDisablePreemptiveGC()                      (threadsuspend.cpp:2223)
  #04  JIT_PInvokeEndRarePath                                 (jithelpers.cpp:1160)

A GC was actively running at crash time. Threads 25/26 are waiting to allocate, Thread 28 is waiting to re-enter cooperative mode after a P/Invoke. Thread 27 crashed at the exact point it would first enter managed code in CallDescrWorkerInternal, suggesting a GC-vs-thread-startup race — the new thread may be attempting to execute code that the GC is in the process of relocating, or hitting a bad method descriptor during collection.

Additional context:

• 391/391 .NET frames symbolicated across all 41 threads
• This is an MSBuild process (thread names include "RequestBuilder", "In-proc Node", "MSBuild LoggingService", etc.)
• Thread 0 (main) is in RunMain → WaitHandle_WaitOneCore, idle and waiting
• BGC thread (35) is idle in bgc_thread_function → GCEvent::Wait
• The crash is intermittent per the reporter ("sometimes it does succeed"), consistent with a race condition

This likely belongs in area-GC-coreclr rather than area-Host.

[steveisok]

Could it be #123966?

If not, 3eda059130 and bcca62f05a are worth looking into. It could be hitting something we missed.

[agocke]

@janvorli Can you take a look?

[dotnet-policy-service]

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