Frequent Crashes After Migrating App from Xamarin to .NET – Crash in libmonosgen

[SejalH96]

Description

After migrating our Android application from Xamarin to .NET 9 (SDK-style project), the app is frequently crashing at runtime. These crashes did not occur in the Xamarin version of the application.

The crash log consistently points to libmonosgen. Based on our observations, the issue is most likely linked to socket communication (continuous data transfer).

StackTrace:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Nokia/Phoenix_00WW/PNX_sprout:11/RKQ1.200906.002/00WW_6_21F:user/release-keys'
Revision: '0'
ABI: 'arm64'
Timestamp: 2025-07-29 17:02:12+0530
pid: 27186, tid: 27295, name: .NET TP Worker  >>> com.matrix.satatyamv <<<
uid: 12401
signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0
    x0  0000006db4729128  x1  0000000000000089  x2  0000000000000002  x3  0000000000000000
    x4  0000000000000000  x5  00000000ffffffff  x6  00000000ffffffff  x7  0000006db46c7118
    x8  0000000000000062  x9  0000000000000089  x10 0000000000000009  x11 0000000000000002
    x12 0000006f9dd0d620  x13 0000000000019020  x14 0000000000000000  x15 0000006f9dc98378
    x16 0000007110496d18  x17 0000007110423bb0  x18 0000006d8c212000  x19 0000000000000002
    x20 0000000000000000  x21 0000006db4729128  x22 0000000000000089  x23 0000006d8cdf3fb8
    x24 0000006d8cdf4000  x25 000000000000000b  x26 0000000000019000  x27 0000006d8bafc000
    x28 0000006d8cdf4000  x29 0000006d8cbf4550
    lr  000000711042786c  sp  0000006d8cbf4530  pc  0000007110423bcc  pst 0000000040000000

backtrace:
      #00 pc 000000000004abcc  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: a6129197241eb9f68acb05fe7e48a951)
      #01 pc 000000000004e868  /apex/com.android.runtime/lib64/bionic/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+144) (BuildId: a6129197241eb9f68acb05fe7e48a951)
      #02 pc 00000000000b5d84  /apex/com.android.runtime/lib64/bionic/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+216) (BuildId: a6129197241eb9f68acb05fe7e48a951)
      #03 pc 00000000002af124  /data/app/~~mKwtPYp6ishWhqqUe85k9w==/com.matrix.satatyamv-ddlwwWPgxKsO6weNgfDhEQ==/lib/arm64/libmonosgen-2.0.so (BuildId: f4843daf60ba28a3199f1b521e660a49e5c2959a)
      #04 pc 000000000029d710  /data/app/~~mKwtPYp6ishWhqqUe85k9w==/com.matrix.satatyamv-ddlwwWPgxKsO6weNgfDhEQ==/lib/arm64/libmonosgen-2.0.so (BuildId: f4843daf60ba28a3199f1b521e660a49e5c2959a)
      #05 pc 0000000000007328  <anonymous:6e15635000>

Reproduction Steps

=> Continuous data transfer using socket communication

Expected behavior

The application should handle socket communication stably without runtime crashes.

Actual behavior

The application frequently crashes with a fatal signal, pointing to libmonosgen.

Regression?

No response

Known Workarounds

No response

Configuration

.Net version: 9.0.4
Platform: Android

Other information

No response

[simonrozsival]

@SejalH96 thanks for opening the issue. Could you please create a repro project with a .NET MAUI client and a server that demonstrates the crash during continuous data transfer over sockets? This would allow us to diagnose and fix the bug. There is little we can do based on just the stack trace you provided.

[BrzVlad]

The stacktrace is also not helpful for figuring out what could be going wrong here. It also seems like it is crashing during a wait, which doesn't seem very likely. I'm copying instructions on how to symbolicate a crash report from some other issue:

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:

1. Put the libraries mentioned in the crash stack trace in a local directory
2. For each of the Microsoft shared libraries (e.g. libmonosgen-2.0.so) run: dotnet-symbol library-name.so
3. The non-Microsoft may or may not have symbols embedded in them, the Android ones should have them.
4. 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]

I would also recommend trying 9.0.7 first, since it has some stability fixes around GC.

[SejalH96]

I have symbolicate the crash which is as follows:

Command: llvm-addr2line -aCifp -e libmonosgen-2.0.so 2af124

0x2af124: mono_os_mutex_lock at /__w/1/s/src/mono/mono/sgen/../../mono/utils/mono-os-mutex.h:105
(inlined by) mono_coop_mutex_lock at /__w/1/s/src/mono/mono/sgen/../../mono/utils/mono-coop-mutex.h:57
(inlined by) sgen_gc_lock at /__w/1/s/src/mono/mono/sgen/sgen-gc.c:3936

Command: llvm-addr2line -aCifp -e libmonosgen-2.0.so 29d710
0x29d710: mono_gc_alloc_vector at /__w/1/s/src/mono/mono/metadata/sgen-mono.c:1117

[BrzVlad]

Thanks! The symbolication does confirm that the thread in question is doing a wait, but I don't see how this can be the crashing thread, since it is just waiting in the kernel. The lock suggests that there might be a GC happening, so there is probably another thread crashing during GC.

Could you please update to 9.0.7 since, as I mentioned, there are some GC fixes included. If still getting GC crash after update, you could also try with <AndroidEnableSGenConcurrent>False</AndroidEnableSGenConcurrent>