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

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

Is this assertion (jit-info.c:918, !ji->async) a known issue in the Mono runtime / JIT for .NET 10 Android ARM64?
Are there any recommended configuration flags or workarounds (runtime/JIT/AOT/trimming-related) to avoid this type of abort in Release builds?
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.

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

@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?

@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.

@BrzVlad

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

@BrzVlad

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

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

@grodryq

@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.

I also have 34 users with this bug.

backtrace: #00 ... /apex/com.android.runtime/lib64/bionic/libc.so (abort+180) #01 ... split_config.arm64_v8a.apk!libmono-android.release.so (xamarin::android::Helpers::abort_application(_LogCategories, char const*, bool, std::__ndk1::source_location)+584)

There are still no Samsung or Xiaomi devices. There are many Oppo, Redmi, Honor, Vivo, Realme devices, mainly with Mediatek chips but a few have Qualcomm chips. Mainly low Ram (4GB). 50% are on Android 14, with the rest 10-16.

The stack trace is very limited and I cant reproduce the bug and there is no clue about where it originates from. It's putting me above Google's "bad behaviour threshold". I don't think I can take the performance hit of turning off trimming or risk the experimental AOT compiler for a production app.

Is this bug so deep and nasty that it will only be fixed by .Net 11? I think I might have to roll back to .Net 9 in that case.

Is it likely to be a bug in my code that is blowing up in the .Net code with no trace? Or is this a bug in the compiler? Or is something being trimmed that shouldn't be?

Should be in the next upcoming .net10 release, fix was merged 2 weeks ago.

@Cheesebaron

@Cheesebaron, it might be interesting for you to investigate why you get into the "APP_SCOUT_WARNING State" on this device during this scenario, probably something on the main thread taking too long time to complete during app init, the MIUIScout App dumped the callstack when it hits the warning:

02-13 12:25:20.789  2929  5890 W MIUIScout App: Event:APP_SCOUT_WARNING Thread:main backtrace:
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at crc64d42650af502c5fe4.OptionsConfigurationCallback.n_configure(Native Method)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at crc64d42650af502c5fe4.OptionsConfigurationCallback.configure(OptionsConfigurationCallback.java:21)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.android.core.SentryAndroid.$r8$lambda$u9xsdYYlOSkKyF7dlRFyeBgNhY4(SentryAndroid.java:143)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.android.core.SentryAndroid$$ExternalSyntheticLambda0.configure(Unknown Source:8)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.Sentry.applyOptionsConfiguration(Sentry.java:270)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.Sentry.init(Sentry.java:240)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.android.core.SentryAndroid.init(SentryAndroid.java:100)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at io.sentry.android.core.SentryAndroid.init(SentryAndroid.java:84)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at crc6472cda14682546623.MainApplication.n_onCreate(Native Method)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at crc6472cda14682546623.MainApplication.onCreate(MainApplication.java:17)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1393)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.app.ActivityThread.handleBindApplication(ActivityThread.java:8398)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2698)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.os.Handler.dispatchMessage(Handler.java:107)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.os.Looper.loopOnce(Looper.java:249)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.os.Looper.loop(Looper.java:337)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at android.app.ActivityThread.main(ActivityThread.java:9687)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at java.lang.reflect.Method.invoke(Native Method)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:625)
02-13 12:25:20.789  2929  5890 W MIUIScout App:     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:944)

with the message:

02-13 12:25:20.788 2929 5803 W MIUIScout App: (Current message: duration=2509ms seq=2 h=android.app.ActivityThread$H w=110)

I am well aware that startup for this App takes a long time. It would take a major rewrite to fix this and we haven't prioritized this. Regardless I don't think it should crash. It doesn't do that on other devices 😅

I am well aware that startup for this App takes a long time. It would take a major rewrite to fix this and we haven't prioritized this. Regardless I don't think it should crash. It doesn't do that on other devices 😅

The crash should be fixed, but I suspect you could get an ANR for this scenario as a result of "APP_SCOUT_WARNING State" triggering when running with fix, but hard to tell since I'm not familiar with how this device operates, so maybe this is just some soft inspection of process, not triggering a full ANR and getting past the crash location, all will continue to operate given that your main thread gets out of unresponsive state quickly.

@lateralusX

Should be in the next upcoming .net10 release, fix was merged 2 weeks ago.

Hi @lateralusX ,

How can I check in which official .NET runtime version (e.g. 10.0.x) it will be included once released?
Is there a way to track when it becomes part of a public release?

Thanks.

@AlessandroLanzoni1991

@AlessandroLanzoni1991, I verified it yesterday on upcoming 10.0.4 release, so when 10.0.4 gets released, it will be included.

[Mono]: Fix stackwalk callbacks calling mono_jit_info_get_method in a…

Hi everyone,

Just a quick update — it looks like .NET 10.0.4-10.0.5 has already been released a couple of days ago.

Has anyone already tested this version to see if the SIGABRT (!ji->async) issue is resolved or at least improved?

It would be really helpful to know if the fix planned for 10.0.4/10.0.x effectively addresses the crashes without requiring workarounds like:

<RunAOTCompilation>false</RunAOTCompilation>

<UseMonoRuntime>false</UseMonoRuntime>

Any feedback or crash metrics from real devices would be greatly appreciated.

Thanks!

Has anyone already tested this version to see if the SIGABRT (!ji->async) issue is resolved or at least improved?

Been testing it in a production build for about a week now. No sight of this crash so far as well as no other regressions. Looks like the update worked!

I too tested in productions and for now (3 days) not see this error!

For us the issue is still present (using Maui 10.0.50 which i assume is equivalent to .NET 10.0.5, correct me if i'm wrong please).
In my case it happens on a Redmi Note 13 Pro+ 5G (Android 16) during startup most likely when performing EF operations on a sqlite database, which would fit cases described earlier in this issue

After updating to .NET SDK 10.0.201 and latest Android workload I cannot reproduce this issue anymore on Redmi Note 15 Pro+ (Android 15)

For us the issue is still present (using Maui 10.0.50 which i assume is equivalent to .NET 10.0.5, correct me if i'm wrong please). In my case it happens on a Redmi Note 13 Pro+ 5G (Android 16) during startup most likely when performing EF operations on a sqlite database, which would fit cases described earlier in this issue

so it seems like when attempting that i was still on an older .NET SDK, after reading the latest comment i double checked and tried again with .NET SDK 10.0.201 and now it works here as well

Navigation Menu

Repository navigation

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

Problem Description

Environment

Affected Devices / OS

Stack Trace (excerpt)

Observed Behavior

Questions

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Problem Description

Environment

Affected Devices / OS

Stack Trace (excerpt)

Observed Behavior

Questions

Activity

MihuBot commented on Dec 31, 2025

steveisok commented on Dec 31, 2025

grodryq commented on Dec 31, 2025

vitek-karas commented on Dec 31, 2025

steveisok commented on Jan 1, 2026

BrzVlad commented on Jan 6, 2026

NatWobble commented on Jan 8, 2026

24 remaining items

lateralusX commented on Feb 20, 2026

lateralusX commented on Feb 20, 2026

Cheesebaron commented on Feb 20, 2026

lateralusX commented on Feb 20, 2026

AlessandroLanzoni1991 commented on Feb 25, 2026

lateralusX commented on Feb 25, 2026

grodryq commented on Mar 14, 2026

ololomax commented on Mar 24, 2026

AlessandroLanzoni1991 commented on Mar 24, 2026

The666Wayfaerer commented on Apr 8, 2026

Cheesebaron commented on Apr 8, 2026

The666Wayfaerer commented on Apr 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions