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)

Most upvoted comments

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. image

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 :

godot-3.2.1-stable/core/object.cpp:941:33 godot-3.2.1-stable/core/variant.cpp:1592:28 godot-3.2.1-stable/core/variant.cpp:1408:9 godot-3.2.1-stable/core/io/json.cpp:117:33 godot-3.2.1-stable/core/io/json.cpp:111:10 godot-3.2.1-stable/core/io/json.cpp:111:10 godot-3.2.1-stable/core/io/json.cpp:111:10 godot-3.2.1-stable/core/io/json.cpp:123:9 godot-3.2.1-stable/core/bind/core_bind.cpp:3210:9 godot-3.2.1-stable/./core/method_bind.gen.inc:2505:17 godot-3.2.1-stable/core/object.cpp:921:17 ` full_bt

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 and armv7): https://send.firefox.com/download/ce4ac3341d7a2601/#XRIXZIyiWUh2oZkBpYSqAg (available for 7 days)

How to use it:

  • If you don’t use “Custom Template/Use Custom Build”, then select the android_debug.apk as “Custom Template/Debug” in your Android preset, and export a Debug build
  • If you use “Custom Template/Use Custom Build”, either:
    • Delete res://android, put the downloaded android_source.zip in your Godot templates/3.2.1.stable folder, use “Install Android Build Template…” from the editor and redo your local changes, or
    • Keep your res://android, unzip android_source.zip somewhat and copy its android_source/libs/debug/godot-lib.debug.aar to res://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 copy bin/godot-lib.debug.aar in place of your installed res://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 of target=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-existing res://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:

scons p=android tools=no target=debug android_arch=arm64v8
scons p=android tools=no target=debug android_arch=armv7
cd platform/android/java
./gradlew generateGodotTemplates

And use the generated bin/android_debug.apk as debug template here: Screenshot_20200520_111758

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:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> com.mvolution.cuarentena1 <<<

backtrace:
  #00  pc 00000000006fe9bc  /data/app/com.mvolution.cuarentena1-xJ_EtKnP9LEu6rrNMiJllg==/lib/arm/libgodot_android.so
  #01  pc 000000000127327c  /data/app/com.mvolution.cuarentena1-xJ_EtKnP9LEu6rrNMiJllg==/lib/arm/libgodot_android.so
  #02  pc 0000000000076278  /data/app/com.mvolution.cuarentena1-xJ_EtKnP9LEu6rrNMiJllg==/lib/arm/libgodot_android.so
  #03  pc 0000000000009137  /data/app/com.mvolution.cuarentena1-xJ_EtKnP9LEu6rrNMiJllg==/oat/arm/base.odex (offset 0x9000)

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.