You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ever since switching from Xamarin.Android to .NET8, and recently to .NET9, we see a crash group which appears in all our releases in GooglePlay Console. Originally we were suspected that this crash group might be related to the "out-of-memory", but we don't see any other alloc-related issues originating from other places.
Interestingly, only a small percentage of reports GooglePlay Console considers to be a "user-perceived" once. We are suspecting that these crashes might be happening when one of our crash monitoring systems (AppCenter, Sentry) is collecting information.
Unfortunately, we haven't found a reliable way to reproduce it manually, but it has a pretty big counter in production (around 0.5% affected sessions)
Did you find any workaround?
No workaround found yet
Relevant log output
************************************************
pid: 0, tid: 2783 >>> <app.bundle.id> <<<
backtrace:
#00 pc 0x0000000000061a28 /apex/com.android.runtime/lib64/bionic/libc.so (je_arena_ralloc_no_move+88)#01 pc 0x0000000000061f2c /apex/com.android.runtime/lib64/bionic/libc.so (je_arena_ralloc+160)#02 pc 0x0000000000059740 /apex/com.android.runtime/lib64/bionic/libc.so (je_realloc+236)#03 pc 0x0000000000053934 /apex/com.android.runtime/lib64/bionic/libc.so (realloc+88)#04 pc 0x00000000001ddba8 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (monoeg_realloc+108)#05 pc 0x00000000001e0720 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (monoeg_g_string_append+105)#06 pc 0x000000000020d820 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (mono_type_get_name_recurse+457)#07 pc 0x000000000020d740 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (mono_type_get_name_recurse+388)#08 pc 0x000000000020daf0 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (mono_type_get_name_recurse+494)#09 pc 0x000000000020daf0 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (mono_type_get_name_recurse+494)#10 pc 0x000000000020d514 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (mono_type_get_name_full+557)#11 pc 0x000000000023cd18 /data/app/~~vrG0vqSsCasZF9aCOcJVQg==/<app.bundle.id>-GHfs8XiUFY5dyQ87mHQkIA==/split_config.arm64_v8a.apk!libmonosgen-2.0.so (ves_icall_System_RuntimeType_getFullName_raw+5131)#12 pc 0x000000000000b2d0
The text was updated successfully, but these errors were encountered:
Android framework version
net8.0-android, net9.0-android
Affected platform version
.NET 8.0.403, .NET 9.0.100
Description
Ever since switching from Xamarin.Android to .NET8, and recently to .NET9, we see a crash group which appears in all our releases in GooglePlay Console. Originally we were suspected that this crash group might be related to the "out-of-memory", but we don't see any other
alloc
-related issues originating from other places.Interestingly, only a small percentage of reports GooglePlay Console considers to be a "user-perceived" once. We are suspecting that these crashes might be happening when one of our crash monitoring systems (AppCenter, Sentry) is collecting information.
We have a lot of similar crash reports: from different architectures (armeabi/arm64), with different levels of recursion, with different realloc implementations, but always from the same place of origin.
crash_symbolicated_example1.txt
crash_symbolicated_example2.txt
crash_symbolicated_example3.txt
crash_symbolicated_example4.txt
Steps to Reproduce
Unfortunately, we haven't found a reliable way to reproduce it manually, but it has a pretty big counter in production (around 0.5% affected sessions)
Did you find any workaround?
No workaround found yet
Relevant log output
The text was updated successfully, but these errors were encountered: