net10.0-ios Release build crashes at startup (MONO_ERROR_CLEANUP_CALLED_SENTINEL / load_aot_module) unless MtouchNoSymbolStrip=true — related to #21908, #18870

[markdou812]

Apple platform

iOS

Framework version

net10.0-*

Affected platform version

iOS 26.6

Description

We have a .NET MAUI app (net10.0-ios, SDK 10.0.102/10.0.201) whose Release/Store configuration crashes on launch on a physical device with a native SIGABRT during Mono runtime startup, before any managed application code runs. This reproduces identically on:

• A local dev Mac (Xcode 26.6, iOS 26.6 device)
• A Microsoft-hosted Azure DevOps macos-26 agent doing a fully clean checkout every run

This looks like the same underlying class of bug reported in #21908 and #18870, but we were able to isolate the triggering property with a controlled A/B test, which I don't think has been reported yet.

Crash signature

error: * Assertion at /Users/runner/work/1/s/src/runtime/src/mono/mono/utils/mono-error.c:156,
condition `error_code != MONO_ERROR_CLEANUP_CALLED_SENTINEL' not met

Native stacktrace:
... mono_log_write_os_log
... monoeg_g_logv
... monoeg_g_log
... load_aot_module
... mono_assembly_request_load_from
... mono_assembly_request_open
... mono_assembly_open
... xamarin_assembly_preload_hook
... invoke_assembly_preload_hook
... mono_assembly_load_corlib
... mono_init
... mini_init
... mono_jit_init
... xamarin_bridge_initialize
... xamarin_main
... main

App terminated due to signal 6. No managed stack trace is produced — the crash occurs before Main/AppDelegate/any application code executes.

Reproducible isolation (A/B test)

We ran two fully-clean builds (rm -rf all bin/obj before each), identical in every property except MtouchNoSymbolStrip:

Build	MtouchNoSymbolStrip	Useinterpreter	MtouchUseLlvm	Result
A	true	true	true	Launches successfully, runs normally
B	false (default)	true	true	Crashes every time with the signature above

This was repeated twice with consistent results in each direction. Since only MtouchNoSymbolStrip changed, and both builds were from a fully clean intermediate state, this points to the Release strip pass removing a symbol that Mono's AOT loader needs at startup to locate the embedded System.Private.CoreLib AOT module — specifically when combined with MtouchUseLlvm=true.

Repro project properties

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Release|net10.0-ios|AnyCPU'">
  <Optimize>True</Optimize>
  <Useinterpreter>True</Useinterpreter>
  <MtouchUseLlvm>True</MtouchUseLlvm>
  <!-- MtouchNoSymbolStrip not set → defaults to symbol stripping → crash -->
</PropertyGroup>

Environment

• .NET SDK: 10.0.102 (CI, pinned via UseDotNet@2) / 10.0.201 (local)
• Xcode: 26.6
• Target device: physical iPhone 15 Pro, iOS 26.6
• CI: Azure DevOps, Microsoft-hosted macos-26 pool, fresh checkout every run (fetchDepth: 1), no cache tasks

Workaround

Adding <MtouchNoSymbolStrip>true</MtouchNoSymbolStrip> to the Release/Store net10.0-ios property group resolves the crash reliably, matching the workaround already suggested by @rolfbjarne in #18870 and used as a diagnostic step in #21908.

Related issues

• Random app crashes on publish in AOT mode #21908 — same load_aot_module stack trace, same "clean sometimes fixes it" symptom, tagged incremental-builds, closed by inactivity bot but still recurring as of May 2025
• [release-test/multi-targetting-net8.0] Update dependencies from xamarin/xamarin-macios #18870 — same "Release crashes, Debug fine" symptom on an earlier SDK; resolved there via interpreter + clean rebuild

Ask

Given MtouchNoSymbolStrip deterministically flips this crash from a fully-clean state (not just intermittently, as in #21908), this may be a more specific reproduction of the same class of bug — the Release native/AOT pipeline appears to depend on symbols that the default strip pass removes. Would appreciate guidance on whether this is expected behavior of the AOT loader's symbol resolution, or a bug in when/how stripping is applied relative to AOT codegen.

Steps to Reproduce

True True True

Did you find any workaround?

Yes, don't allow symbol stripping.

Relevant logs

No response