Critical SIGABRT crash in .NET 10 Android (ARM64) – Assertion jit-info.c:918 (!ji->async)

[grodryq]

Problem Description

We are experiencing abrupt application terminations (SIGABRT) in production on Android for an application built with .NET 10 (Release). The process exits without any managed C# exception due to an internal Mono runtime assertion.

Reported error:

Assertion at /mono/metadata/jit-info.c:918,
condition `!ji->async` not met

The runtime explicitly calls abort() via xamarin::android::Helpers::abort_application, causing the app to terminate immediately.

---

Environment

• Framework: .NET 10.0
• Configuration: Release
• Architecture: arm64-v8a
• Platform: Android
• Distribution: Google Play (Production)

---

Affected Devices / OS

• Devices: Xiaomi / Redmi models (e.g., Redmi Note series)
• SoC: Predominantly MediaTek
• Android versions: 13 (SDK 33), 14 (SDK 34), 15 (SDK 35)

No comparable crashes have been observed so far on Samsung or Google Pixel devices.

---

Stack Trace (excerpt)

* Assertion at /__w/1/s/src/runtime/src/mono/mono/metadata/jit-info.c:918,
condition `!ji->async' not met

pid: 0, tid: 8117 >>> com.companyname.biliApp <<<

#00 libc.so (abort+164)
#01 libmono-android.release.so
    xamarin::android::Helpers::abort_application(...)

---

Observed Behavior

• Occurs only in Release builds
• Not reproducible in Debug or emulators
• No managed stack trace or catchable .NET exception
• The failure happens inside the Mono runtime before control returns to application code

---

Questions

1. Is this assertion (jit-info.c:918, !ji->async) a known issue in the Mono runtime / JIT for .NET 10 Android ARM64?
2. Are there any recommended configuration flags or workarounds (runtime/JIT/AOT/trimming-related) to avoid this type of abort in Release builds?
3. Is there awareness of similar issues on MediaTek-based devices, or plans for a service release addressing this behavior?

Thank you for any guidance you can provide.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• [mono] Assertion at jit-info.c:918, condition '!ji->async' #121404

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @vitek-karas
See info in area-owners.md if you want to be subscribed.

[steveisok]

@grodryq do you have a repro that you can share?

Also, are you getting this with the default configuration? If not, what settings do you have enabled?

[grodryq]

@grodryq do you have a repro that you can share?

Also, are you getting this with the default configuration? If not, what settings do you have enabled?

Thanks for the quick response.

Repro: unfortunately I don’t have a reliable minimal repro at this time. The crash is not reproducible on our side in Debug or on emulators. It has only been observed in Production via Google Play Console crash reports on real devices.

Configuration: this happens with our standard Release build for net10.0-android (arm64-v8a). We are not enabling any unusual runtime flags. If you can point me to the exact properties you want verified (AOT/LLVM, trimming/linking, R8/proguard, interpreter), I can paste the relevant csproj Release settings and the workload/SDK versions.

Additional context: the affected devices are predominantly Xiaomi/Redmi models (often MediaTek) running Android 13–15. The Play Console stack shows:
Assertion at .../mono/metadata/jit-info.c:918, condition '!ji->async' not met
followed by xamarin::android::Helpers::abort_application(...) in libmono-android.release.so.

Let me know what additional diagnostics/logs would be most useful and I’ll provide them.

[dotnet-policy-service]

Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

@BrzVlad this looks pretty much exactly like #121404, but that issue possibly covers multiple problems.

[steveisok]

@BrzVlad this looks pretty much exactly like #121404, but that issue possibly covers multiple problems.

@vitek-karas have we tested on Xiaomi devices yet?

[BrzVlad]

@grodryq Some people have reported using <RunAOTCompilation>false</RunAOTCompilation> in order to workaround this issue. So that would be the first thing to try out. We haven't been able to look into this issue since there was no repro provided yet. Debug builds use a different runtime configuration so it would make sense to not reproduce locally, if attempting to reproduce you should try with Release configuration instead.