// ------------------------// ------------------------------------------------------------------

Investigation Summary: dotnet/runtime#126516

Failure Pattern

8 failing builds across 3 platforms (ARM64 Linux, x64 Linux, macOS x64) all show the
identical crash:

┌────────────────────┬────────────────┐
│ Platform           │ Build IDs      │
├────────────────────┼────────────────┤
│ ARM64 Ubuntu 22.04 │ b1, b2         │
├────────────────────┼────────────────┤
│ x64 Ubuntu 22.04   │ b3, b4, b5, b6 │
├────────────────────┼────────────────┤
│ macOS x64          │ b7, b8         │
└────────────────────┴────────────────┘

All failures occur in System.Runtime.Tests → ArrayTests.CastAs_IListOfT().

Crash Stack (from crash report JSON + dotnet-dump)

 SIGSEGV / Access Violation

 System.Runtime.CompilerServices.CastHelpers.StelemRef_Helper(ref, long, object)
 System.Runtime.CompilerServices.CastHelpers.StelemRef(ref, long, object)  ← INLINED, absent
from stack
 SZArrayHelper.set_Item(int, T)
 System.Tests.ArrayTests+<>c.<CastAs_IListOfT>b__197_1(IList<string>)
 ...

The StelemRef frame is absent from the native stack because PR #117583 inlined it into
SZArrayHelper.set_Item. The crash occurs inside StelemRef_Helper which was called because the
element type check failed with a NULL elementType.

Dump Analysis (x86_64 — build b3)

Faulting instruction in SZArrayHelper.set_Item[String] (Tier1 OptimizedTier1):

 ; At RIP = 0x7e97bde7b43c inside SZArrayHelper.set_Item:
 mov  rsi, qword ptr [rip - 0x6cfc80b]   ; loads from absolute address 0x7e97b717ec38

This loads elementType from a hardcoded constant address 0x7e97b717ec38.

Memory verification:

 ; The constant address is SZArrayHelper.MethodTable + 0x38 (ElementType offset in Checked
builds)
 dp 0x7e97b717ec38 → 0x0000000000000000   ← NULL! (SZArrayHelper is not an array, has no
ElementType)

 ; The actual array being stored to is String[] with a DIFFERENT MethodTable:
 dumpmt <String[].MT>  → ElementType at +0x38 = valid String MethodTable pointer

Dump Analysis (ARM64 — build b1)

Identical pattern confirmed via ARM64 dump (analyzed using dotnet-dump + Cross-DAC ARM64):

 ; Builds constant 0xf796beedec38 = SZArrayHelper.MT + 0x38, then loads:
 mov  x14, #0xec38
 movk x14, #0xbeed, lsl #16
 movk x14, #0xf796, lsl #32
 ldr  x1, [x14]          ; loads elementType = 0x0 (NULL)

Memory verification:

 dp 0xf796beedec38 → 0x0000000000000000   ← NULL (same bug, same pattern)

Regression Source

PR #117583 ("Inline CORINFO_HELP_ARRADDR_ST helper call, remove WriteBarrier FCall") by
@EgorBo — merged 2026-04-02T20:23:28Z, ~24 hours before all failures appeared. 

This PR converted stelem.ref from a JIT helper call to an inlined managed call to
CastHelpers.StelemRef(). The inlining exposed a pre-existing JIT type-tracking bug that was
dormant when StelemRef was compiled as a standalone helper.

Root Cause: JIT Constant-Folds GetMethodTable(array) Using Wrong MethodTable

The bug is in how the JIT's Unsafe.As<T> intrinsic interacts with VN-based constant folding.
Here is the exact call chain:

Step 1 — this gets "exact type" SZArrayHelper (lclvars.cpp:2687-2694)

When SZArrayHelper.set_Item<T> is compiled at Tier1, the this parameter has declared type
SZArrayHelper. In lvaSetClass():

 if (clsHnd != NO_CLASS_HANDLE && !isExact && JitConfig.JitEnableExactDevirtualization())
 {
     CORINFO_CLASS_HANDLE exactClass;
     if (info.compCompHnd->getExactClasses(clsHnd, 1, &exactClass) == 1)
     {
         isExact = true;   // ← SZArrayHelper is sealed, so this fires
         clsHnd  = exactClass;
     }
 }

SZArrayHelper is sealed with no subclasses, so getExactClasses returns 1 → this is marked
lvClassIsExact = true. But SZArrayHelper is a phantom type — the CLR redirects IList<T>
interface calls on arrays to SZArrayHelper methods, so at runtime this is always an array
like String[], never actually SZArrayHelper.

Step 2 — Unsafe.As<T[]>(this) fails to update the type (importercalls.cpp:5220-5227)

The method body does Unsafe.As<T[]>(this) to reinterpret this as an array. The JIT handles
this intrinsic:

 CORINFO_CLASS_HANDLE oldClass = gtGetClassHandle(op, &isExact, &isNonNull);
 // oldClass = SZArrayHelper, inst = T[]
 if ((oldClass != NO_CLASS_HANDLE) &&
     ((oldClass == inst) || !info.compCompHnd->isMoreSpecificType(oldClass, inst)))
 {
     JITDUMP("Unsafe.As: Keep using old '%s' type\n", eeGetClassName(oldClass));
     return op;  // ← BUG: Returns original node, type stays SZArrayHelper!
 }

isMoreSpecificType(SZArrayHelper, T[]) asks "is T[] more specific than SZArrayHelper?" The VM
calls MergeTypeHandlesToCommonParent(SZArrayHelper, T[]) → merged = System.Object (unrelated
types) → merged != SZArrayHelper → returns false. So !false = true → condition is true →
keeps the old SZArrayHelper type instead of creating a temp with type T[].

Step 3 — StelemRef is inlined, GetMethodTable(array) creates invariant IND (
compiler.hpp:1884-1890)

PR #117583 converts stelem.ref to a call to CastHelpers.StelemRef() which gets inlined.
Inside the inlined body, RuntimeHelpers.GetMethodTable(array) expands to:

 GenTreeIndir* result = gtNewIndir(TYP_I_IMPL, object, GTF_IND_INVARIANT | GTF_IND_NONNULL);

This creates IND(array) flagged as invariant — telling the JIT "the MethodTable of an object
never changes."

Step 4 — VN constant-folds using the wrong MethodTable (valuenum.cpp:12588-12614)

During value numbering, the JIT sees IND(array, GTF_IND_INVARIANT) and tries to resolve it:

 if (tree->gtFlags & GTF_IND_INVARIANT)
 {
     if ((oper == GT_IND) && addr->TypeIs(TYP_REF) && tree->TypeIs(TYP_I_IMPL))
     {
         CORINFO_CLASS_HANDLE handle = gtGetClassHandle(addr, &isExact, &isNonNull);
         if (isExact && (handle != NO_CLASS_HANDLE))   // isExact=true from Step 1!
         {
             void* embedClsHnd = (void*)info.compCompHnd->embedClassHandle(handle,
&pEmbedClsHnd);
             ValueNum handleVN = vnStore->VNForHandle((ssize_t)embedClsHnd,
GTF_ICON_CLASS_HDL);
             tree->gtVNPair = vnStore->VNPWithExc(ValueNumPair(handleVN, handleVN),
addrXvnp);
             // ← Assigns SZArrayHelper.MethodTable as a CONSTANT value number!
         }
     }
 }

gtGetClassHandle(array) returns SZArrayHelper with isExact=true (propagated from Step 1
through Step 2). The VN engine embeds SZArrayHelper.MethodTable as a compile-time constant.

Step 5 — Assertion propagation replaces IND with constant (assertionprop.cpp:2719+)

optVNBasedFoldConstExpr sees the constant VN and replaces the IND node with
gtNewIconHandleNode(SZArrayHelper.MethodTable).

Step 6 — Runtime crash

The JIT-generated code loads ElementType from SZArrayHelper.MethodTable + 0x38:

 - SZArrayHelper.MT + 0x38 = 0x0 (NULL) — SZArrayHelper is not an array, it has no element
type
 - The code compares elementType against the value being stored, comparison fails (NULL ≠
anything)
 - Falls through to StelemRef_Helper(ref, NULL_elementType, obj) → dereferences NULL →
SIGSEGV

Proposed Fix

Location: importercalls.cpp line 5223 — change the Unsafe.As<T> type-keeping condition from:

 ((oldClass == inst) || !info.compCompHnd->isMoreSpecificType(oldClass, inst))

to:

 ((oldClass == inst) || info.compCompHnd->isMoreSpecificType(inst, oldClass))

Why this works: The current code asks "is inst NOT more specific than oldClass?" — which is
true for unrelated types (like SZArrayHelper vs T[]), incorrectly keeping the stale type. The
fix asks "IS oldClass more specific than inst?" — which is false for unrelated types, so it
correctly falls through to create a new temp with the target type T[].

This preserves the existing optimization for the normal case: Unsafe.As<Base>(derivedObj) →
isMoreSpecificType(Base, Derived) = true → keeps the more precise Derived type. ✓

Note: The corinfo.h documentation for isMoreSpecificType explicitly states: "This is a hint
to the jit for optimization; it does not have correctness implications." The current code at
line 5223 violates this contract by using the hint for a correctness-critical decision.

This is a pre-existing JIT bug exposed by PR #117583's inlining change. Before that PR,
StelemRef was compiled as a standalone helper with no caller type context, so the VN
constant-fold path was never reached. Once StelemRef was inlined into SZArrayHelper.set_Item,
the caller's (incorrect) type info for this propagated into the inlined body and triggered
the constant fold.

Root Cause: JIT Constant-Folds GetMethodTable(array) Using Wrong MethodTable

The bug is a pre-existing JIT type-tracking issue involving Unsafe.As<T> on a phantom
type (SZArrayHelper), exposed by inlining StelemRef which brought
GetMethodTable(array)->ElementType into scope of VN-based constant folding.

Call chain (with source locations)

Step 1 — this gets type SZArrayHelper (lclvars.cpp:486)

lvaInitThisPtr calls lvaSetClass(this, info.compClassHnd) where info.compClassHnd =
SZArrayHelper. On CoreCLR, getExactClasses returns -1, so lvClassIsExact stays false.

Step 2 — Unsafe.As<__Canon[]>(this) fails to update the type (
importercalls.cpp:5220-5226)

 CORINFO_CLASS_HANDLE oldClass = gtGetClassHandle(op, &isExact, &isNonNull);
 if ((oldClass != NO_CLASS_HANDLE) &&
     ((oldClass == inst) || !info.compCompHnd->isMoreSpecificType(oldClass, inst)))
 {
     return op;  // ← BUG: keeps SZArrayHelper type!
 }

oldClass = SZArrayHelper, inst = __Canon[]. These are unrelated types.
isMoreSpecificType(SZArrayHelper, __Canon[]) asks "is __Canon[] a subtype of
SZArrayHelper?" → calls MergeTypeHandlesToCommonParent → merged = System.Object (neither
is parent) → merged != SZArrayHelper → returns false. So !false = true → the condition
is true → returns the original node with type SZArrayHelper still attached.

Note: inside gtGetClassHandle, at gentree.cpp:19414-19424, the type is also promoted to
exact:

 if (!*pIsExact && JitConfig.JitEnableExactDevirtualization())
 {
     if (getExactClasses(objClass, 1, &exactClass) == 1) { ... } // returns -1 on 
CoreCLR
     else
     {
         *pIsExact = info.compCompHnd->isExactType(objClass); // SZArrayHelper is sealed
 → TRUE
     }
 }

isExactType(SZArrayHelper) returns true because SZArrayHelper is sealed (pMT->IsSealed()
at jitinterface.cpp:4463). But SZArrayHelper is a phantom type — the CLR redirects
IList<T> interface calls on arrays to SZArrayHelper methods, so this is always an array
at runtime, never a real SZArrayHelper instance.

Step 3 — PR #117583 inlines StelemRef (importercalls.cpp, importer.cpp:7268)

stelem.ref → CORINFO_HELP_ARRADDR_ST → impConvertToUserCallAndMarkForInlining() converts
the helper to a managed call to CastHelpers.StelemRef(array, index, value) and marks it
for inlining. The array argument traces back to the local that still has type
SZArrayHelper.

Step 4 — GetMethodTable(array) creates invariant IND (compiler.hpp:1884-1890)

Inside the inlined StelemRef, RuntimeHelpers.GetMethodTable(array) expands to:

 GenTreeIndir* result = gtNewIndir(TYP_I_IMPL, object, GTF_IND_INVARIANT |
GTF_IND_NONNULL);

GTF_IND_INVARIANT tells the JIT "the MethodTable of an object never changes."

Step 5 — VN constant-folds using the wrong MethodTable (valuenum.cpp:12588-12614)

 if (tree->gtFlags & GTF_IND_INVARIANT)
 {
     if ((oper == GT_IND) && addr->TypeIs(TYP_REF) && tree->TypeIs(TYP_I_IMPL))
     {
         CORINFO_CLASS_HANDLE handle = gtGetClassHandle(addr, &isExact, &isNonNull);
         if (isExact && (handle != NO_CLASS_HANDLE))    // isExact=true (from 
isExactType!)
         {
             if (!eeIsSharedInst(handle))                // SZArrayHelper is not shared 
→ passes
             {
                 void* embedClsHnd = (void*)info.compCompHnd->embedClassHandle(handle,
&pEmbedClsHnd);
                 ValueNum handleVN = vnStore->VNForHandle((ssize_t)embedClsHnd,
GTF_ICON_CLASS_HDL);
                 tree->gtVNPair = vnStore->VNPWithExc(ValueNumPair(handleVN, handleVN),
addrXvnp);
                 // ← Assigns SZArrayHelper.MethodTable as a CONSTANT value number
             }
         }
     }
 }

gtGetClassHandle(addr) returns SZArrayHelper with isExact=true (from isExactType at Step
2). eeIsSharedInst(SZArrayHelper) = false. The VN engine embeds
SZArrayHelper.MethodTable as a compile-time constant.

Step 6 — Assertion propagation replaces IND with constant (assertionprop.cpp:2719+)

optVNBasedFoldConstExpr sees the constant VN and replaces the IND node with a constant
handle node pointing to SZArrayHelper.MethodTable.

Step 7 — Runtime crash

The JIT-generated code loads ElementType from SZArrayHelper.MethodTable + 0x38 → NULL.
Comparison with obj->MT fails. Falls to StelemRef_Helper(ref element, NULL, obj) →
IsInstanceOfAny_NoCacheLookup(NULL, obj) → dereferences NULL → SIGSEGV.

Two Contributing Bugs

(A) Primary — importercalls.cpp:5222-5226 (Unsafe.As intrinsic)

The condition !isMoreSpecificType(oldClass, inst) is true for unrelated types (like
SZArrayHelper vs __Canon[]), causing the JIT to keep the stale SZArrayHelper type
instead of creating a new temp with type __Canon[]. The corinfo.h documentation for
isMoreSpecificType explicitly states: "This is a hint to the jit for optimization; it
does not have correctness implications" — but this code uses it for a
correctness-critical decision.

Possible fix: Change the condition to only keep the old type when it's provably a
subtype:

 // Before (buggy): keeps old type for unrelated types
 ((oldClass == inst) || !info.compCompHnd->isMoreSpecificType(oldClass, inst))

 // After (fixed): only keeps old type when it's MORE specific than target
 ((oldClass == inst) || info.compCompHnd->isMoreSpecificType(inst, oldClass))

(B) Secondary — gentree.cpp:19424 (gtGetClassHandle exactness promotion)

isExactType(SZArrayHelper) returns true because SZArrayHelper is sealed. But
SZArrayHelper is a phantom type — no runtime object ever has its MethodTable. Marking it
exact enables VN constant-folding of GetMethodTable() loads, which produces wrong code.

Possible defense-in-depth: The VM could exclude phantom types like SZArrayHelper from
isExactType, or the JIT could avoid constant-folding MethodTable loads when the class
has CORINFO_FLG_ARRAY == 0 for a type that is the declaring class of an array interface
method.