godot: arm64 libgodot_android.so crash Android 10
3.2.1.stable
ANDROID 10/Google Pixel 3 XL:
Issue description: Google Play Console found my game crash on Android 10/Google Pixel 3 Xl. Here is the backtrace. I don’t know what is the source of that issue cause it didn’t happen on any of my devices. Anyway i am creating an issue here.
Google Pixel 3 XL (crosshatch), 3584MB RAM, Android 10
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.karolstudios.pixelz <<<
backtrace:
#00 pc 0000000001087904 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#01 pc 00000000006cfdec /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#02 pc 000000000101eb1c /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#03 pc 000000000109dc94 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#04 pc 0000000000307840 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#05 pc 00000000002e64f8 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#06 pc 00000000006bd6dc /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#07 pc 000000000101d040 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#08 pc 00000000006be924 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#09 pc 00000000006c2790 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#10 pc 00000000006b384c /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#11 pc 000000000101eb1c /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#12 pc 0000000001018014 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#13 pc 0000000001018260 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#14 pc 00000000006db35c /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#15 pc 000000000017bc60 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so
#16 pc 00000000001536d8 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/lib/arm64/libgodot_android.so (Java_org_godotengine_godot_GodotLib_step+164)
#17 pc 00000000000101b0 /data/app/com.karolstudios.pixelz-oAB0kwpMxkRmsYnb5k0XKw==/oat/arm64/base.odex (art_jni_trampoline+144)
#18 pc 0000000002004344 /memfd:/jit-cache (org.godotengine.godot.GodotRenderer.onDrawFrame+84)
#19 pc 00000000020107a8 /memfd:/jit-cache (android.opengl.GLSurfaceView$GLThread.guardedRun+3976)
#20 pc 000000000013663c /apex/com.android.runtime/lib64/libart.so (art_quick_osr_stub+60)
#21 pc 0000000000333acc /apex/com.android.runtime/lib64/libart.so (art::jit::Jit::MaybeDoOnStackReplacement(art::Thread*, art::ArtMethod*, unsigned int, int, art::JValue*)+1660)
#22 pc 00000000005a30f0 /apex/com.android.runtime/lib64/libart.so (MterpMaybeDoOnStackReplacement+212)
#23 pc 0000000000135350 /apex/com.android.runtime/lib64/libart.so (MterpHelpers+240)
#24 pc 00000000002d2e3e /system/framework/framework.jar (android.opengl.GLSurfaceView$GLThread.guardedRun+682)
#25 pc 000000000059a8a4 /apex/com.android.runtime/lib64/libart.so (MterpInvokeDirect+1168)
#26 pc 0000000000130914 /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_direct+20)
#27 pc 00000000002d35cc /system/framework/framework.jar (android.opengl.GLSurfaceView$GLThread.run+48)
#28 pc 00000000002b03a8 /apex/com.android.runtime/lib64/libart.so (art::interpreter::Execute(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame&, art::JValue, bool, bool) (.llvm.15430740532710954497)+240)
#29 pc 000000000058980c /apex/com.android.runtime/lib64/libart.so (artQuickToInterpreterBridge+1012)
#30 pc 000000000013f468 /apex/com.android.runtime/lib64/libart.so (art_quick_to_interpreter_bridge+88)
#31 pc 0000000000136334 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_stub+548)
#32 pc 000000000014506c /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+244)
#33 pc 00000000004a9b0c /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
#34 pc 00000000004aaba0 /apex/com.android.runtime/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue const*)+416)
#35 pc 00000000004ea93c /apex/com.android.runtime/lib64/libart.so (art::Thread::CreateCallback(void*)+1176)
#36 pc 00000000000e1100 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#37 pc 0000000000083ab0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 42 (22 by maintainers)
In the Google Play dashboard you can filter out devices in the Device catalog section. One of the filters you can use to browse is the amount of RAM. It’s not the most convenient experience, but doable at least.
There’s a plan about having the option to have those checks in release builds too and even add further protections.
I haven’t had time to write the proposal yet.
That was hard ! Crashlytics does not work for me … *.so libs are stripped in the apk, but I finally learned about ndk-stack tool. give him a dir where unstripped libraries are and you’re good. So has I thought, problems comes from JSON serialisation …
GDScript code is :
fout.store_line(JSON.print(dict))
bt is :
Thanks a lot @RandomShaper. I was not aware of that powerful capability. Also discovered Reach and Devices which provides more helpful insights.
Thanks again!
Hoooo sorry, that’s harsh ! I already tried to publish a release apk built with the android_debug.apk, it has be detected and refused. I’ll complete crashlytics setup and upload the debug symbols to crashlytics. Yes, I forgot to mention google-services.json …
Here’s a
target=debug
build of 3.2.1-stable for Android (arm64v8
andarmv7
): https://send.firefox.com/download/ce4ac3341d7a2601/#XRIXZIyiWUh2oZkBpYSqAg (available for 7 days)How to use it:
android_debug.apk
as “Custom Template/Debug” in your Android preset, and export a Debug buildres://android
, put the downloadedandroid_source.zip
in your Godottemplates/3.2.1.stable
folder, use “Install Android Build Template…” from the editor and redo your local changes, orres://android
, unzipandroid_source.zip
somewhat and copy itsandroid_source/libs/debug/godot-lib.debug.aar
tores://android/build/libs/debug/
to replace the existing one. (Recommended as you don’t need to mess with your installed Godot templates and redo your Android customization, but I’m only 95% confident that doing this is sufficient - should be good enough though 😃)See the last part of my previous comment, you’d need to build the Godot export template with debug symbols (see Compiling for Android).
Then it’s a bit tricky as the new workflow with custom build templates doesn’t allow to easily use one’s own
android_source.zip
to set things up (until #36728 is fixed).Since you’re using 3.2.1-stable as is, the best might be that once you have built the export template using the above instructions with
target=debug
, you can copybin/godot-lib.debug.aar
in place of your installedres://android/build/libs/debug/godot-lib.debug.aar
. I haven’t tested but that should add the necessary debug symbols while still allowing you to use the template source installed from 3.2.1-stable.To have a full debug stacktrace when it crashes, you should build custom export templates with
target=debug
instead oftarget=release_debug
(what “Debug” templates use by default).They will be significantly bigger but will include full debug symbols so that the crash in
libgodot_android.so
can give us a detailed stacktrace.Also to be sure, please verify that you’re are building the export templates properly from the same commit and local modifications as the editor. If you’re using the “Custom Build” option, you should also reinstall the custom compiled
android_source.zip
in place of your pre-existingres://android/build/
which might have been installed with the official 3.2.1-stable (which is thus not compatible with your custom changes).Edit: I might have misinterpreted that you have custom changes made to the template. If you’re using the stock Android template from the Godot 3.2.1 templates package, then you just need to rebuild a custom debug templates from the
3.2.1-stable
git tag, with:And use the generated
bin/android_debug.apk
as debug template here:And export with “Debug” on of course so that this debug template is used.
I get quite a lot of remote crash reports (Crashlyics) from my android game, that look exactly like this (crash in libgodot_android.so), and to a lesser extend crashes in other .so binaries too. Please, how can I attach debug symbols to these reports? I would like to help you guys fix these problems.
In the crashlytics docu they say I need to execute
./gradlew crashlyticsUploadSymbolsRelease
but in a godot project I have no idea where/how to execute that? Please, could you guide us in a general direction?This problem is rather urgend, because crashes like this produce 1-star ratings in google play for games that would have great ratings otherwise. Quite a big bummer!
Most crash reports I get look like this:
Some other .so libraries report crashes too, but not as many.
My users complain about the app crashing on startup - others about a black screen, sound is starting but nothing more.
I have Crashlytics up and running and would like to upload debugging symbols to the Crashlytics backend to provide you guys with meaningful backtraces from various devices out there in the wild. I’m kind of lost on how to do that. Any ideas?
I’m afraid a backtrace without debugging symbols isn’t of much use, especially if the user who got the crash isn’t around to reply to our questions.