App crashes on launch when deployed to Google Play #5619
Assignees
Labels
Area: App Runtime
Issues in `libmonodroid.so`.
possibly-stale
Issues that are potentially no longer relevant.
Milestone
Comments
grendello
added a commit
to grendello/xamarin-android
that referenced
this issue
Feb 12, 2021
Context: dotnet#5619 It appears that Xamarin.Android application uploaded to Google Console internal Test Track can fail the pre-launch test because the `MonodroidRuntime::get_java_class_name_for_TypeManager` method, can sometimes get a `nullptr` Java class name from JNI: Build fingerprint: 'google/blueline/blueline:9/PQ3A.190801.002/5670241:user/release-keys' Revision: 'MP1.0' ABI: 'arm64' pid: 15773, tid: 15773, name: com.Myapp >>> com.Myapp<<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 Cause: null pointer dereference x0 0000000000000000 x1 0000000000000000 x2 0000000000000000 x3 00000000000000e1 x4 0000000000000000 x5 0000000000000305 x6 0000000000000006 x7 0000000000000010 x8 0101010101010101 x9 4adfd1b7ed2e23e2 x10 0000000000430000 x11 000000000000000a x12 0000000000000002 x13 0000000000000001 x14 00000000000000a8 x15 000000000000000a x16 0000007f703f00f8 x17 0000007f7031f290 x18 0000000000000008 x19 0000000000000000 x20 0000007eecae0460 x21 0000000000000000 x22 0000000000000000 x23 0000000000000099 x24 0000000000000085 x25 0000007eecb30010 x26 0000000000000099 x27 0000000000000000 x28 0000007f724255e0 x29 0000007fe01ad010 sp 0000007fe01acff0 lr 0000007f7036f3b4 pc 0000007f7031f2a0 backtrace: #00 pc 000000000001e2a0 /system/lib64/libc.so (strlen+16) #1 pc 000000000006e3b0 /system/lib64/libc.so (strdup+20) #2 pc 000000000000d4e8 /data/app/com.Myapp-1lufsJe3FIZ0YHoEAB08KA==/split_config.arm64_v8a.apk (offset 0x165d000) (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+92) #3 pc 000000000005f6d0 <anonymous:0000007ecc4ac000> This can happen if either one of the below points is true: 1. The Java [`Class.getName`](https://developer.android.com/reference/java/lang/Class?hl=en#getName()) method is absent 2. `Class.getName` returns `nullptr` (a nameless class?) 3. `env->GetStringUTFChars` returns `nullptr` (a memory allocation failure?) Out of these, 3. appears to be most probable and this commit adds a check for a `nullptr` pointer there, failing gracefully instead of segfaulting. This is NOT a fix for the original problem as we don't know by what it is caused but, nevertheless, the `nullptr` check should be there.
|
@Glomby the crash happens right in this code, however it would happen only if one of the items below were true:
Out of these, I suspect 3., however unlikely it is. opened a PR to fail gracefully in this instance. |
|
@grendello I just finished testing this fix. I wasn't able to build xamarin.android in the release configuration (only in debug) so I couldn't test it in die Google Play Console but as far as I know these tests are the same as the Firebase Test Lab Tests. I still need to test this a little more but I haven't seen this crash so far and for the first time ever I was able to get a successful test result. |
grendello
added a commit
to grendello/xamarin-android
that referenced
this issue
Feb 16, 2021
Context: dotnet#5619 It appears that Xamarin.Android application uploaded to Google Console internal Test Track can fail the pre-launch test because the `MonodroidRuntime::get_java_class_name_for_TypeManager` method, can sometimes get a `nullptr` Java class name from JNI: Build fingerprint: 'google/blueline/blueline:9/PQ3A.190801.002/5670241:user/release-keys' Revision: 'MP1.0' ABI: 'arm64' pid: 15773, tid: 15773, name: com.Myapp >>> com.Myapp<<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 Cause: null pointer dereference x0 0000000000000000 x1 0000000000000000 x2 0000000000000000 x3 00000000000000e1 x4 0000000000000000 x5 0000000000000305 x6 0000000000000006 x7 0000000000000010 x8 0101010101010101 x9 4adfd1b7ed2e23e2 x10 0000000000430000 x11 000000000000000a x12 0000000000000002 x13 0000000000000001 x14 00000000000000a8 x15 000000000000000a x16 0000007f703f00f8 x17 0000007f7031f290 x18 0000000000000008 x19 0000000000000000 x20 0000007eecae0460 x21 0000000000000000 x22 0000000000000000 x23 0000000000000099 x24 0000000000000085 x25 0000007eecb30010 x26 0000000000000099 x27 0000000000000000 x28 0000007f724255e0 x29 0000007fe01ad010 sp 0000007fe01acff0 lr 0000007f7036f3b4 pc 0000007f7031f2a0 backtrace: #00 pc 000000000001e2a0 /system/lib64/libc.so (strlen+16) #1 pc 000000000006e3b0 /system/lib64/libc.so (strdup+20) #2 pc 000000000000d4e8 /data/app/com.Myapp-1lufsJe3FIZ0YHoEAB08KA==/split_config.arm64_v8a.apk (offset 0x165d000) (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+92) #3 pc 000000000005f6d0 <anonymous:0000007ecc4ac000> This can happen if either one of the below points is true: 1. The Java [`Class.getName`](https://developer.android.com/reference/java/lang/Class?hl=en#getName()) method is absent 2. `Class.getName` returns `nullptr` (a nameless class?) 3. `env->GetStringUTFChars` returns `nullptr` (a memory allocation failure?) Out of these, 3. appears to be most probable and this commit adds a check for a `nullptr` pointer there, failing gracefully instead of segfaulting. This is NOT a fix for the original problem as we don't know by what it is caused but, nevertheless, the `nullptr` check should be there.
jonpryor
pushed a commit
that referenced
this issue
Feb 18, 2021
…5623) Context: #5619 It appears that Xamarin.Android application uploaded to Google Play Console internal Test Track can fail the pre-launch test because the `MonodroidRuntime::get_java_class_name_for_TypeManager()` method can sometimes get a `nullptr` Java class name from JNI: Build fingerprint: 'google/blueline/blueline:9/PQ3A.190801.002/5670241:user/release-keys' Revision: 'MP1.0' ABI: 'arm64' pid: 15773, tid: 15773, name: com.Myapp >>> com.Myapp<<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 Cause: null pointer dereference x0 0000000000000000 x1 0000000000000000 x2 0000000000000000 x3 00000000000000e1 x4 0000000000000000 x5 0000000000000305 x6 0000000000000006 x7 0000000000000010 x8 0101010101010101 x9 4adfd1b7ed2e23e2 x10 0000000000430000 x11 000000000000000a x12 0000000000000002 x13 0000000000000001 x14 00000000000000a8 x15 000000000000000a x16 0000007f703f00f8 x17 0000007f7031f290 x18 0000000000000008 x19 0000000000000000 x20 0000007eecae0460 x21 0000000000000000 x22 0000000000000000 x23 0000000000000099 x24 0000000000000085 x25 0000007eecb30010 x26 0000000000000099 x27 0000000000000000 x28 0000007f724255e0 x29 0000007fe01ad010 sp 0000007fe01acff0 lr 0000007f7036f3b4 pc 0000007f7031f2a0 backtrace: #00 pc 000000000001e2a0 /system/lib64/libc.so (strlen+16) #1 pc 000000000006e3b0 /system/lib64/libc.so (strdup+20) #2 pc 000000000000d4e8 /data/app/com.Myapp-1lufsJe3FIZ0YHoEAB08KA==/split_config.arm64_v8a.apk (offset 0x165d000) (xamarin::android::internal::MonodroidRuntime::get_java_class_name_for_TypeManager(_jclass*)+92) #3 pc 000000000005f6d0 <anonymous:0000007ecc4ac000> This can happen if either one of the below points is true: 1. [`java.lang.Class.getName()`][0] returns `nullptr` (a nameless class? This seems unlikely.) 2. [`JNIEnv::GetStringUTFChars()`][1] returns `nullptr` (a memory allocation failure?) Of these, (2) appears to be most probable; regardless, add appropriate `nullptr` checks for each of them, failing gracefully instead of segfaulting. This is NOT a fix for the original problem as we don't know by what it is caused but, nevertheless, the `nullptr` check should be there. [0]: https://developer.android.com/reference/java/lang/Class?hl=en#getName() [1]: https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#GetStringUTFChars
|
We suspect this issue is stale and no longer relevant. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. |
|
This issue will now be closed since it had been marked |
ghost
locked as resolved and limited conversation to collaborators
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
I wasn't able to reproduce this crash on my end. Non of my physical devices or emulated devices have done this so far. I can download the App from the play store onto my physical devices and run it. I have not seen it crash like that. The pre-launch test crashes everytime though.
It would greatly help to understand the type of crash and maybe find a way to actually reproduce it on my end. Even downloading the .apks that Google Play generates and installing them manually on my physical devices has never caused a crash.
Expected Behavior
App launches successfully.
Actual Behavior
Crashes during Splash Screen
Version Information
Microsoft Visual Studio Professional 2019
Version 16.8.5
VisualStudio.16.Release/16.8.5+31005.135
Microsoft .NET Framework
Version 4.8.04084
Xamarin 16.8.000.262 (d16-8@4d60f9c)
Visual Studio-Erweiterung, um Entwicklung für Xamarin.iOS und Xamarin.Android zu ermöglichen.
Xamarin.Android SDK 11.1.0.26 (d16-8/a36ce73)
Xamarin.Android Reference Assemblies and MSBuild support.
Mono: 5e9cb6d
Java.Interop: xamarin/java.interop/d16-8@79d9533
ProGuard: Guardsquare/proguard@ebe9000
SQLite: xamarin/sqlite@1a3276b
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-8@2fb1cbc
Log File
All the crashes look pretty much the same and end up here: "..get_java_class_name_for_TypeManager(_jclass*)"
Here are two reports, but all the other crash reports I'm getting look pretty much the same.
Native Crash on Google Pixel 3 Android 9 (SDK 28)
Or another crash on a Nokia 1 Android 8.1 (SDK27)
Full logcat for the crash on a google Pixel 3.
logcat.txt
The text was updated successfully, but these errors were encountered: