.NET iOS: App sporadically crashes after NFC read when returning a large struct (Data). Changing it to a class fixes it — why?

[alyimran]

Platform / Build

• .NET 9 (net9.0-ios) – Xamarin/.NET for iOS
• iOS 17 (device)
• AOT + UseInterpreter=true
• TrimMode=partial in Release
• App uses CoreNFC (ISO7816) to read a meter, then decodes frames into a big Data type

Symptom

• After an NFC scan, we build up a large Data value type (lots of nested structs/fields).
• Returning that Data from the decode/read path sometimes crashes the app right after the last Console.WriteLine (no managed exception is seen).
• If I instead return new Data() (i.e., don’t return the fully-populated struct), the app never crashes.
• If I change Data from a struct to a class, the crash disappears completely and everything works.
  So the only change that consistently fixes it is turning the large return type from struct → class.

Relevant code (simplified)

// Large result type (originally a struct; switching to class makes crash go away)
public /*struct*/ class Data
{
    public Cap Cap;
    public Types Type;
    public General General;
    public Main Main;
    // ... many nested value types & arrays ...
}

// Decode on iOS
public override Data Read(Modes mode)
{
    var frame = GetFrames();
    Console.WriteLine("[trace] getframes completed.");

    var result = Decode(frame); // ← builds a big Data value

    Console.WriteLine("[trace] decode completed.");

    // If I do this (return the real struct), I get sporadic native crashes:
    // return result;

    // If I do this (dummy), it never crashes:
    return new Data();
}

// The hot function (simplified): fills `Result` then returns it
public virtual Data Decode(MBus.Frame frame)
{
    Result.Cap = Cap;
    // ... many assignments into nested fields ...
    Console.WriteLine("[trace] Returning Result data");
    return Result; // ← returning a big struct
}

If I change Data to a class and update code accordingly, crashes stop.

Minimal native crash excerpt (from .ips)
No managed stack/exception shows. It’s a native abort:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Crashed Thread:  7

Thread 7 Crashed:
0   UltraConnect.iOS          mono_sigsegv_signal_handler_debug
1   UltraConnect.iOS          mono_handle_native_crash
2   UltraConnect.iOS          mono_dump_native_crash_info
3   libsystem_platform.dylib  _sigtramp

So: native SIGSEGV right after we finish building/returning the large struct; no managed exception surfaces.

What we tried

• Verified it’s not UI-thread misuse: crash occurs after decoding completes, on return.
• Added granular logging inside Decode — last log prints; crash happens during/after return path.
• If we read but don’t assign (connectedMeter.Read(Modes.More);) it doesn’t crash. Assigning the returned struct to a variable or passing it onward does (sporadically).
• Switching Data from struct → class eliminates the crash entirely (Android and WPF were always fine).

Question
Why would returning a very large, deeply nested struct from AOT’d .NET iOS code cause sporadic native SIGABRT (no managed exception), while the exact same logic works on Android/WPF — and switching that type to a class fixes it on iOS?

• Is this a known JIT/AOT / marshalling / stack frame issue with large value types on .NET for iOS?
• Are there size/complexity thresholds for value types that can trigger ABI issues during return/copy?
• Any guidance from the runtime/ABI perspective on iOS about returning large structs (copy elision, stack vs. hidden return buffer, interpreter interaction, trimming, etc.)?

Any pointers to best practices (e.g., prefer classes for large DTOs on iOS, use ref struct/in/out patterns, or known fixes/workarounds) would be hugely appreciated.

[hez2010]

From the symptom it can be caused by stack overflow.

[SkyDevLab]

The reason changing Data from a struct to a class completely resolves your crash comes down to how ARM64 calling conventions, Mono interpreter thunks, and iOS thread stack limits interact.

1. ARM64 Calling Convention (AAPCS64) and Indirect Return (X8)

Under the ARM64 Procedure Call Standard (AAPCS64):

• Value types $\le$ 16 bytes (or Homogeneous Floating-Point Aggregates) are returned directly in CPU registers (X0–X7 or V0–V3).
• Structs larger than 16 bytes cannot be returned in registers. Instead, the caller must allocate a buffer on its stack and pass the address of that buffer in register X8 (the indirect result location register). The callee then copies the struct into [X8].

2. The Mono Interpreter / AOT Boundary (UseInterpreter=true)

Because you have UseInterpreter=true on iOS:

• Whenever code crosses an interpreter-to-AOT or AOT-to-interpreter boundary (which frequently occurs during virtual dispatch or SDK callbacks), Mono must synthesize a marshaling thunk.
• For large structs, the interpreter allocates an InterpFrame and must execute a deep memory copy into the caller's X8 buffer. When returning new Data(), fields are unpopulated and memory pages may remain untouched, but returning a fully populated, deeply nested struct forces full memory writes across multiple stack frames.

3. iOS Thread Stack Limits (512 KB)

On iOS, callbacks from system frameworks like CoreNFC are dispatched on Grand Central Dispatch (GCD) worker threads.

• Unlike desktop Windows/Linux or Android (which typically have 1 MB–2 MB stacks), iOS GCD worker threads often have a default stack size of only 512 KB.
• Deeply nested value types copied by value across Read $\rightarrow$ Decode $\rightarrow$ caller assignment quickly consume stack space. When the stack collides with the OS guard page, the kernel immediately issues EXC_BAD_ACCESS (SIGSEGV) via mono_sigsegv_signal_handler_debug.

4. Why Switching to a class Eliminates the Crash

When Data is a class:

1. It is a reference type: the return value is a single 8-byte pointer passed directly in register X0.
2. Register X8 and stack return buffers are bypassed completely.
3. No struct memory copying occurs across interpreter stack frames.
4. Thread stack consumption drops from kilobytes per call to 8 bytes.

Best Practice

Per the .NET Framework Design Guidelines:

AVOID defining a struct unless the type has an instance size under 16 bytes.

Large DTOs containing nested arrays and domain data should always be declared as class. If value semantics are strictly required, pass them by reference (in Data / ref readonly Data) rather than returning them by value across virtual method boundaries.