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

Build Information

Build: 20251105.5, 20251105.1, 20251104.5

Build error leg or test failing: Loader.WorkItemExecution, the specific test failing is ExtendedLayoutTests.ExtendedLayout.ExtendedLayout_NoExtendedLayoutAttribute

Affected CI jobs: linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT_RuntimeTests

Commit range: started to fail on 10/14 2025, but there's a large hole in data before that date, so it's possible it was earlier.

Summary

Native crash triggered by SIGABRT from Mono runtime assertion failure during test execution
Failures occur on linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT_RuntimeTests job on linux x64 platform
AOT-only mode fails to load 'ExtendedLayout.dll.so', causing runtime errors in mono/metadata/jit-info.c
Mono runtime assertion at line 918 fails with condition '!ji->async' not met during test
Tests exit with code 0 instead of expected 100, resulting in test failure with exit code 1

Work Items

Work Item

Job Name

Build

Console Log

Loader

linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT_RuntimeTests

20251105.5

View Extract

=================================================================
	Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

...
03:02:15.733 Running test: _ExtendedLayout::ExtendedLayoutTests.ExtendedLayout.ExtendedLayout_NoExtendedLayoutAttribute()
Failed to load AOT module '/datadisks/disk1/work/A14E093D/w/97AB0850/e/Loader/Loader/ExtendedLayout.dll.so' ('/datadisks/disk1/work/A14E093D/w/97AB0850/e/Loader/Loader/ExtendedLayout.dll') in aot-only mode.


=================================================================
	Native Crash Reporting
=================================================================


...

=================================================================
	Managed Stacktrace:
=================================================================
  at <unknown> <0xffffffff>
* Assertion at /__w/1/s/src/mono/mono/metadata/jit-info.c:918, condition `!ji->async' not met
App Exit Code: 0
Expected: 100
Actual: 0
END EXECUTION - FAILED
+ test_exit_code=1

Full Log

Loader

linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT_RuntimeTests

20251105.1

View Extract

=================================================================
	Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

14:54:10.861 Running test: _ExtendedLayout::ExtendedLayoutTests.ExtendedLayout.ExtendedLayout_NoExtendedLayoutAttribute()
Failed to load AOT module '/datadisks/disk1/work/A4560917/w/A41B08D0/e/Loader/Loader/ExtendedLayout.dll.so' ('/datadisks/disk1/work/A4560917/w/A41B08D0/e/Loader/Loader/ExtendedLayout.dll') in aot-only mode.

=================================================================
	Managed Stacktrace:
=================================================================
  at <unknown> <0xffffffff>
* Assertion at /__w/1/s/src/mono/mono/metadata/jit-info.c:918, condition `!ji->async' not met
App Exit Code: 0
Expected: 100
Actual: 0
END EXECUTION - FAILED
+ test_exit_code=1

Full Log

Loader

linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT_RuntimeTests

20251104.5

View Extract

=================================================================
	Native Crash Reporting
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

=================================================================
	Native stacktrace:

...
02:55:15.378 Running test: _ExtendedLayout::ExtendedLayoutTests.ExtendedLayout.ExtendedLayout_NoExtendedLayoutAttribute()
Failed to load AOT module '/datadisks/disk1/work/AEE109AB/w/B2FB09E9/e/Loader/Loader/ExtendedLayout.dll.so' ('/datadisks/disk1/work/AEE109AB/w/B2FB09E9/e/Loader/Loader/ExtendedLayout.dll') in aot-only mode.


=================================================================
	Native Crash Reporting
=================================================================


...

=================================================================
	Managed Stacktrace:
=================================================================
  at <unknown> <0xffffffff>
* Assertion at /__w/1/s/src/mono/mono/metadata/jit-info.c:918, condition `!ji->async' not met
App Exit Code: 0
Expected: 100
Actual: 0
END EXECUTION - FAILED
+ test_exit_code=1

Full Log

Error Message

{
  "ErrorMessage": [
    "Failed to load AOT module",
    "* Assertion at /__w/1/s/src/mono/mono/metadata/jit-info.c:918, condition \u0060!ji-\u003Easync\u0027 not met"
  ],
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Notes

The test only fails on the linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT configuration, it passes in all other configs.

Report

Build	Definition	Test	Pull Request
1196167	dotnet/runtime	Loader.WorkItemExecution

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
1	1	1

Report

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	0

This is likely related to #119948 (maybe even a duplicate)
There's a second issue that this test should be disabled for mono:

runtime/src/tests/Loader/classloader/ExtendedLayout/ExtendedLayout.csproj

Line 6 in 6e1e6b1

But it still runs in the linux_x64_Release_AllSubsets_Mono_LLVMFULLAOT configuration (note that it currently doesn't run on any other configuration in extra-platforms).

[tests] Disable ExtendedLayout test on fullaotllvm (#121630)

I started noticing some intermittent crashes in my Android application, and after analyzing the log, the reason is exactly as mentioned in the description of this issue.

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

8049 8336 F libc : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 8336 (Finalizer), pid 8049 (mydomain.myapp)

I added <MonoAotIncompatible>true</MonoAotIncompatible> to my csproj and now I will observe if the issue happens again.
I will keep you informed about this.

@luronumen

I also see many Assertion at /__w/1/s/src/runtime/src/mono/mono/metadata/jit-info.c:918, condition `!ji->async' not met after I released my app on NET10 with all nugets updated to latest versions. Before NET9 worked with no issues.

@luronumen were you able to solve the issue?

what if to add UseInterpreter true ?

@rburnashev85

Hi @rburnashev85 ,

Because this is an intermittent issue, we will only be able to confirm that the <MonoAotIncompatible>true</MonoAotIncompatible> workaround worked within a few days.

Hi Guys,

The issue persists even after setting <MonoAotIncompatible>true</MonoAotIncompatible>.

Do you have any other suggestions for an workaround to this issue?

The correct way to disable AOT would be to add <RunAOTCompilation>false</RunAOTCompilation>. If on .net10, you could also try using the coreclr runtime instead, but note that this is currently experimental (See https://learn.microsoft.com/en-us/dotnet/maui/whats-new/dotnet-10?view=net-maui-10.0#experimental-coreclr). A full symbolicated stacktrace or repro would be useful in order to investigate this. To symbolicate the trace, you will need:

dotnet-symbol tool (dotnet tool -g install dotnet-symbol)
Android NDK or any LLVM toolchain which contains the llvm-addr2line utility

After the above are available, follow these steps:

Put the libraries mentioned in the crash stack trace in a local directory
For each of the Microsoft shared libraries (e.g. libmonosgen-2.0.so) run: dotnet-symbol library-name.so
The non-Microsoft may or may not have symbols embedded in them, the Android ones should have them.
For each interesting frame from the trace collect the frame address (the pc column in the trace, prefix 0x is optional, as are all the leading zeros) and the library name and run: llvm-addr2line -aCifp -e library-name.so frame_address

For instance, for the trace line:

#00 pc 0x00000000000d77a4 /data/app/~~9Zfo4zOl7WqWCiDvRydiaQ==/com.example.app-enZujLkwQVZO0lw0cRXUvA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (BuildId: 67228244379e0d7698287264cbddfcea8c1e1cb3)

We'd run:

llvm-addr2line -aCifp -e libmonosgen-2.0.so d77a4

@BrzVlad

Hi @BrzVlad ,

Thank you so much for your detailed description of this issue!

I replaced <MonoAotIncompatible>true</MonoAotIncompatible> with <RunAOTCompilation>false</RunAOTCompilation> in the csproj file and generated a new version of my Android application.

I will test it over the next few days and keep you informed if the issue happens again.

With 'RunAOTCompilation = false' I'm still getting sigabrt issue, but with a different error "/apex/com.android.art/lib64/libart.so (art::JNI::GetObjectClass(_JNIEnv*, _jobject*)+324)".

Prior to RunAOTCompilation I was getting lots of async errors as per this thread, so looks like RunAOTCompilation=false fixed async error, but introduced this one as I've never seen it before.

Hi all, just to know if a proper runtime fix has been found. If possible, I don't want to lose startup performance using false. Thanks a lot.

I actually took the plunge and switched to CoreCLR using false and so far, after about a week I haven't had a single sigabrt.

I did some startup benchmarking and found that CoreCLR was about on par, or even slightly quicker than monoAOT.

It is of course, still experimental, so maybe not be suitable for you. But so far, I've found it to be perfectly stable.

We updated to MAUI 10 and this was completely stable on internal builds but is now blowing up our crash metrics in Google Play Store. Is there a fix planned or in the works?

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

There is a fix targeting 10.0.4 for these assertions.

People used <RunAOTCompilation>false</RunAOTCompilation> as a workaround. As another alternative, I would also encourage you to try out the experimental coreclr support <UseMonoRuntime>false</UseMonoRuntime>. While still experimental, it is a configuration that we are focusing on.

I am also seeing these errors show up in Google Play crash logs. Is there any plan to fix the underlying problem since this did not happen with .NET 9? The workarounds are not an actual fix. Disabling AOT degrades app performance. Also, I believe CoreCLR does not support the android-arm RID, which means dropping support for a bunch of devices.

Our app has now gone above the bad behavior threshold because of this crash. Microsoft should consider this crash a serious issue because the frequency of the crash can affect visibility in Google Play Store thus impact revenue:

If your app or game exceeds a bad behavior threshold, Play may reduce the visibility of your title. Play may also show users a warning on your store listing.

https://developer.android.com/topic/performance/vitals#how_do_core_vitals_affect_my_titles_visibility_on_play

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!

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!

Just to confirm, MAUI 10.0.40 fixes the issue or MAUI 10.0.50 will?

Just to confirm, MAUI 10.0.40 fixes the issue or MAUI 10.0.50 will?

I'm on 10.0.4

This assert was fixed in #122797 back in February 2026 and have been backported into .net10, 10.0.4.

Navigation Menu

Repository navigation

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

Build Information

Summary

Work Items

Error Message

Notes

Report

Summary

Report

Summary

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Build Information

Summary

Work Items

Error Message

Notes

Report

Summary

Report

Summary

Activity

vitek-karas commented on Nov 7, 2025

luronumen commented on Dec 4, 2025

rburnashev85 commented on Dec 8, 2025

luronumen commented on Dec 8, 2025

luronumen commented on Dec 10, 2025

BrzVlad commented on Dec 10, 2025

luronumen commented on Dec 11, 2025

15 remaining items

dzebas commented on Feb 7, 2026

gtrafford commented on Feb 8, 2026

mnxamdev commented on Feb 25, 2026

BrzVlad commented on Feb 25, 2026

mjo151 commented on Feb 25, 2026

mnxamdev commented on Feb 25, 2026

grodryq commented on Mar 14, 2026

ololomax commented on Mar 24, 2026

mnxamdev commented on Mar 24, 2026

ololomax commented on Mar 25, 2026

lateralusX commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions