NativeAOT arm64: loop over a preinitialized static array of structs reads the array through an unrelocated object handle (movz/movk), crashing with an access violation

Start with the arm64 disassembly for Mesh in the issue and compare the movz/movk sequence that reads Faces with the relocated adrp/add sequence elsewhere in the method. Reproduce with the provided project using NativeAOT and --codegenopt:JitDisasm=Mesh, then trace how the frozen array reference and struct copy are handled in the arm64 code generator. Done when the generated access uses a valid relocated address and the program prints faces drawn: 2560 on arm64.

Description

Compiled with NativeAOT for arm64, a foreach over a static readonly array of structs that ILC preinitializes (a frozen object) can load the array's elements through a movz/movk immediate whose value is ILC's opaque object handle for the array (0x42xxxx), with no relocation. Every other reference to the same array in the method is an adrp/add pair with a relocation. At run time the immediate is not an address, so the first element read faults.

It happens when the element is copied out to a stack local (here, a 72-byte struct passed by value to non-inlined methods) inside a loop with enough else live. A simpler loop over the same array compiles correctly.

We hit it in a game: an Apple Silicon Mac build crashed the moment it ran the loop. We reproduced it on Windows by cross-compiling the same code for win-arm64 with an older ILCompiler, so it does not seem specific to one release or to macOS. The x64 builds of the same code run correctly.

Reproduction Steps

repro.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
  </PropertyGroup>
</Project>

Program.cs:

using System.Runtime.CompilerServices;

Console.WriteLine($"faces drawn: {Repro.Mesh(new byte[18 * 18 * 18])}");

static class Repro
{
    private readonly record struct Face(int Nx, int Ny, int Nz, (int X, int Y, int Z) Base, (int X, int Y, int Z) Across, (int X, int Y, int Z) Up, byte Side);

    private static readonly Face[] Faces =
    [
        new(0, 1, 0, (0, 1, 1), (1, 0, 0), (0, 0, -1), 0),
        new(0, -1, 0, (0, 0, 0), (1, 0, 0), (0, 0, 1), 1),
        new(1, 0, 0, (1, 0, 1), (0, 0, -1), (0, 1, 0), 2),
        new(-1, 0, 0, (0, 0, 0), (0, 0, 1), (0, 1, 0), 2),
        new(0, 0, 1, (0, 0, 1), (1, 0, 0), (0, 1, 0), 2),
        new(0, 0, -1, (1, 0, 0), (-1, 0, 0), (0, 1, 0), 2),
    ];

    [MethodImpl(MethodImplOptions.NoInlining)]
    public static int Mesh(byte[] blocks)
    {
        for (int i = 0; i < blocks.Length; i += 3)
        {
            blocks[i] = 1;
        }

        Span<float> corners = stackalloc float[12];
        Span<float> uvs = stackalloc float[8];
        Span<float> shades = stackalloc float[4];
        int drawn = 0;
        for (int y = 0; y < 16; y++)
        {
            for (int z = 0; z < 16; z++)
            {
                for (int x = 0; x < 16; x++)
                {
                    byte block = At(blocks, x, y, z);
                    if (block == 0)
                    {
                        continue;
                    }

                    float top = block == 2 ? 0.875f : 1f;
                    foreach (Face face in Faces)
                    {
                        if (At(blocks, x + face.Nx, y + face.Ny, z + face.Nz) != 0 && !(face.Side == 0 && top < 1f))
                        {
                            continue;
                        }

                        Corners(face, x, y, z, top, corners);
                        Texture(face.Side, uvs);
                        Shade(blocks, face, x, y, z, shades);
                        drawn += Quad(corners, face.Nx, face.Ny, face.Nz, uvs, shades);
                    }
                }
            }
        }

        return drawn;
    }

    private static byte At(byte[] blocks, int x, int y, int z) => blocks[(((y + 1) * 18) + z + 1) * 18 + x + 1];

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void Corners(Face face, int x, int y, int z, float top, Span<float> corners)
    {
        for (int i = 0; i < 4; i++)
        {
            int across = i is 1 or 2 ? 1 : 0;
            int up = i >= 2 ? 1 : 0;
            corners[i * 3] = x + face.Base.X + (across * face.Across.X) + (up * face.Up.X);
            corners[(i * 3) + 1] = y + MathF.Min(face.Base.Y + (across * face.Across.Y) + (up * face.Up.Y), top);
            corners[(i * 3) + 2] = z + face.Base.Z + (across * face.Across.Z) + (up * face.Up.Z);
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void Texture(byte side, Span<float> uvs) => uvs.Fill(side / 4f);

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static void Shade(byte[] blocks, Face face, int x, int y, int z, Span<float> shades)
    {
        for (int i = 0; i < 4; i++)
        {
            shades[i] = At(blocks, x + face.Nx + face.Across.X, y + face.Ny + face.Across.Y, z + face.Nz + face.Up.Z) == 0 ? 1f : 0.6f;
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    private static int Quad(Span<float> corners, int nx, int ny, int nz, Span<float> uvs, Span<float> shades) =>
        corners[0] + uvs[0] + shades[0] + nx + ny + nz > -100f ? 1 : 0;
}

On an arm64 machine: dotnet publish -c Release -r osx-arm64 (or linux-arm64), then run the executable.

To see the code without an arm64 machine, cross-compile from win-x64 by running ILC on the response file a win-x64 publish writes, with --targetarch:arm64, the win-arm64 references, and --codegenopt:JitDisasm=Mesh.

Expected behavior

faces drawn: 2560, as the x64 build and dotnet run print.

Actual behavior

In the game this was cut down from, the same loop stopped an osx-arm64 build (ILCompiler 10.0.14) with an access violation, KERN_INVALID_ADDRESS at 0x000000000046ec80. This program compiles to the same unrelocated constant; we have not yet run it on an arm64 machine.

The JIT's listing for Mesh (ILCompiler 10.0.11, win-x64 host, --targetarch:arm64):

G_M000_IG11:
            mov     x8, #16
            mov     w9, #6
            ...
G_M000_IG12:
            movz    x0, #0x9C8
            movk    x0, #66 LSL #16          ; 0x4209C8: no RELOC
            add     x0, x8, x0
            ldr     x4, [x0, #-0xD8]
            str     x4, [fp, #-0xD8]
            ldp     q0, q16, [x0, #-0xD0]
            stp     q0, q16, [fp, #-0xD0]
            ldp     q0, q16, [x0, #-0xB0]
            stp     q0, q16, [fp, #-0xB0]
G_M000_IG13:
            add     x8, x8, #72

Elsewhere in the same method the array is reached with a relocation:

            adrp    x1, [HIGH RELOC #0x4209F0]
            add     x1, x1, [LOW RELOC #0x4209F0]

The induction variable starts at the first element's offset (16) and steps by sizeof(Face) (72). The array's handle, with the copy's displacement folded in, is emitted as a plain constant.

Regression?

We don't know. The unrelocated constant appears with ILCompiler 10.0.11 (this program and the game) and 10.0.14 (the game).

Known Workarounds

• ILC --nopreinitstatics (<IlcArg Include="--nopreinitstatics" />): the array is not frozen and the loop loads the static normally.
• Iterating by reference over a span may avoid the copy; we haven't verified it.

None of the release JIT's knobs we tried avoided it, among them JitConstCSE 1–4, JitEnableStrengthReduction=0, JitEnableInductionVariableOpts=0, JitEnablePhysicalPromotion=0, JitEnregStructLocals=0, JitNoInline=1 and JitEnableOptRepeat=0.

Configuration

• .NET SDK 10.0.400 with ILCompiler 10.0.11 on Windows 10 x64, cross-compiling for win-arm64 (listing above).
• .NET SDK 10.0.403 with ILCompiler 10.0.14 on macOS 26.5 (Apple M4), osx-arm64: the game crashed at run time.
• x64 builds of the same code run correctly.

Other information

The values involved fall in the range ILC hands the JIT as object handles. In the game's object file the frozen array itself was ___FrozenObj_..._Mesher2 at a different address, and the faulting constant was handle+displacement.