macOS 26 / arm64: SIGSEGV in tier-1 JIT code aborts an ASP.NET Core process under request load; DOTNET_TieredCompilation=0 fixes it

[walljm]

Description

On macOS 26.6.1 / arm64, an ASP.NET Core server reliably takes a SIGSEGV inside JIT-compiled code under
ordinary request load. The fault is converted to AccessViolationException, classified as
corrupting-state, and fail-fasted, so the process dies rather than the request failing.

The same binary and the same data do not reproduce it on macOS 15.7.9, and Linux x64 is unaffected under
considerably heavier load. Disabling tiered compilation stops it outright; disabling only dynamic PGO
reduces it by roughly two orders of magnitude without eliminating it. That combination is what makes me
think this is a tier-1 codegen problem on macOS 26 rather than anything in my code.

I do not yet have a minimal repro — see the last section.

Reproduction Steps

1. Publish an ASP.NET Core (Razor Pages) app self-contained and single-file for osx-arm64:

   dotnet publish -c Release -r osx-arm64 --self-contained true \
     -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true

2. Run it on macOS 26.6.1 / arm64 as a launchd daemon, backed by a PostgreSQL database with enough rows
   that the page's queries do real work.
3. Open a page whose panels each re-poll a fragment endpoint (GET /dashboard?fragment=…) every 30
   seconds, and leave it open.

Expected behavior

The process serves the polls.

Actual behavior

The process aborts. Measured on one host, per fragment poll:

Setting	Crash rate
default	0.33 per poll
DOTNET_TieredPGO=0	0.004 per poll
DOTNET_TieredCompilation=0	none in ~400 polls

So roughly one poll in three killed the process at defaults, and only turning tiering off held.

The native chain from a full dump:

PAL_DispatchException → HandleHardwareException → FailFastIfCorruptingStateException → PROCAbort

The managed stack points at Razor Pages model binding and QueryStringEnumerable. I do not think that is
the bug's location so much as the hottest span-heavy code on the request path, and therefore the code most
likely to have been rejitted at tier 1 by the time the fault happens. Turning tiering off means that code
is never produced, which is consistent with the rate table above.

Regression?

Not a .NET regression as far as I can tell — the OS is the variable. Same binary, same database copy, 1,600
requests on macOS 15.7.9: no crash. The only change that reproduces it is the OS version.

Known Workarounds

DOTNET_TieredCompilation=0. On a launchd daemon:

sudo plutil -replace EnvironmentVariables.DOTNET_TieredCompilation -string "0" /path/to/daemon.plist

DOTNET_TieredPGO=0 alone is not sufficient — it cuts the rate by ~80x but the process still dies.

Configuration

• .NET 10 (net10.0), SDK 10.0.300, self-contained single-file publish
• macOS 26.6.1, arm64 (Apple silicon)
• ASP.NET Core Razor Pages, Kestrel terminating TLS, PostgreSQL via Npgsql
• Does not reproduce: macOS 15.7.9 arm64 (same binary, same data), linux-x64 (heavier load)

Other information

What I have and can supply on request: the full dump, and the managed and native stacks in more detail.
One thing worth recording for anyone else collecting one — createdump refuses anything but
DOTNET_DbgMiniDumpType=4 for a single-file app.

What I do not have is a minimal repro. The fault needs the page's queries to do real work, which in my case means a populated database; an empty one does not reproduce it. I could not reduce it to something self-contained without guessing at which part of the load matters. If a JIT triage on the stacks and the tiering correlation narrows it to a suspected method or optimisation, I am happy to build a targeted repro against that hypothesis, or to run instrumented builds or DOTNET_JitDisasm-style diagnostics on the affected host — it reproduces there within about a minute, so the feedback loop is short.

[AndyAyersMS]

What hardware is this running on (eg M1, M4, ...)?

Please share the dump if you can. One way is to open an issue on https://developercommunity.visualstudio.com/dotnet and attach it there, then link to that issue here.

[walljm]

Apple M4 (Mac mini, Mac16,10), 10 cores (4P/6E), 16 GB, macOS 26.6.1 (25G76).

Dump captured, from a signal 6 abort: 6.07 GiB full, 1.66 GiB compressed. Only full is available here. I will upload it to Developer Community and link it here.

[walljm]

Additional detail from collecting the dump, and one correction to the report above.

DOTNET_TieredCompilation=0 is no longer holding for me. The rate table in the issue was measured on an earlier build of the same app; on the current one I took 7 aborts in a single session with that setting in place, at four sites I had not seen before:

Microsoft.AspNetCore.Http.RequestCookieCollection.Parse
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponseHeaders.SetValueFast
Microsoft.Extensions.Internal.PropertyActivator`1[__Canon].GetActivatableProperties
System.MemoryExtensions.Sort[__Canon]

I am not claiming the earlier measurement was wrong, only that turning tiering off does not appear to be sufficient here any more. If it is genuinely reaching code that tiering never rejits, a tier-1 codegen fault is the wrong theory and I would rather say so than have you chase it.

Every fault is the same shape regardless of site: SIGSEGV converted to AccessViolationException, classified corrupting-state, fail-fast, signal 6. Earlier sites were Claim..ctor, BrotliEncoder.InitializeEncoder and SessionMiddleware. There is no single method to point at, and all of them are span- or buffer-heavy paths on the request route.

Timing has a clear shape. Aborts cluster in the first few minutes after process start and then stop: three in the four minutes after one restart, then an 11-minute clean run, then zero in a deliberately quiet 4.5-minute window with no requests from me. Under an open dashboard it aborts within about a minute of a restart, repeatably. That warm-up correlation is why I originally read it as rejit.

Dump: 6.07 GiB, 5.1 s to write, 1.66 GiB compressed. It is a full memory image of a server process, so it contains a database password, an HMAC secret and TLS key material. I will rotate those first and then get it to you through a channel that is not public.

[EgorBo]

Might be fixed by #131432, should be in 10.0.12

[AndyAyersMS]

I will rotate those first and then get it to you through a channel that is not public.

The VS community uploads are visible only to us Microsoft folks.

[walljm]

Dump uploaded: https://developercommunity.visualstudio.com/t/Crash-dump-for-dotnetruntime132627---A/11141038

It is attached there in five parts, because 1.66 GiB is past what that form takes as one file. The ticket has the reassembly command and a sha256 of the reassembled archive. The parts carry a .dmp extension only to satisfy the attachment filter; individually they are not dumps.

Two things worth adding while I was collecting it.

Anonymous request load does not reproduce it. 6000 requests at concurrency 30, with cookie headers, against a Razor page and a health endpoint: zero aborts. I mention it because RequestCookieCollection.Parse and HttpResponseHeaders.SetValueFast are both in my list of crash sites, and this says those sites really are incidental rather than the thing being exercised. What reproduces it is an authenticated dashboard whose fragment polls run real database queries, which matches "the page's queries do real work" in the original report and is why I could not reduce it to something self-contained.

[walljm]

Tested #131432 as far as I can from a released runtime, and it does not look like the cause here. I also have a sharper characterisation that reconciles the two different crash rates I have quoted.

Regions off does not stop it. I ran the app against libclrgc.dylib (the standalone segment-based GC) taken from the 10.0.11 osx-arm64 runtime pack, which is the same runtime the single-file binary bundles, and confirmed with vmmap that it was actually loaded rather than silently ignored. Same host, same binary, same database, one variable at a time:

Config	Result
TieredCompilation=0 + libclrgc (regions off)	2 aborts at startup, then 0 in 10 min under 388 authenticated fragment polls
default tiering + libclrgc (regions off)	25 aborts in 12 min, process dying ~11 s after each start
TieredCompilation=0 + default GC (regions)	7 aborts in the first ~5 min, then 0 in 44 min under 1610 polls

The two regions-off rows bracket the two GCs at equal tiering settings and come out the same, so switching GC made no clear difference. If the g_gc_lowest_address range-expansion path were what I am hitting, disabling regions should have removed it.

Tiering is clearly the dominant variable regardless of GC: 25 aborts against 0 under otherwise identical conditions.

The dump in the Developer Community ticket is from the tiering-on config, so it is a steady-state crash rather than a warm-up one.