7

My app crashes on Android 10 devices with the following call stack:

backtrace:
#00  pc 000000000006f06c  /apex/com.android.runtime/lib64/bionic/libc.so (abort+160)
#01  pc 00000000000500fc  /system/lib64/libc++.so (abort_message+232)
#02  pc 0000000000050218  /system/lib64/libc++.so (demangling_terminate_handler()+44)
#03  pc 00000000000646c4  /system/lib64/libc++.so (std::__terminate(void (*)())+12)
#04  pc 000000000006466c  /system/lib64/libc++.so (std::terminate()+52)
#05  pc 00000000000bb150  /system/lib64/libc++.so (std::__1::thread::~thread()+20)
#06  pc 00000000000d0f48  /apex/com.android.runtime/lib64/bionic/libc.so (__cxa_finalize+212)
#07  pc 00000000000cc930  /apex/com.android.runtime/lib64/bionic/libc.so (exit+24)
#08  pc 0000000000032f30  /data/app/com.domain.myapp-Rs_sm5VrLR1Jj8QW6oYByA==/lib/arm64/libplugins_platforms_qtforandroid_arm64-v8a.so

I have no idea when and why this happens, because I can't reproduce this on my devices and emulators, but this intensively happens at the user side and only on Android 10 (not on previous Android versions).

My QT version is 5.14.2.

Dmitriano
  • 1,878
  • 13
  • 29
  • 2
    From the callstack alone I'd guess the `std::thread` destructor is being invoked while the thread is still joinable. Hence the [call to `terminate`](https://en.cppreference.com/w/cpp/thread/thread/%7Ethread). Can only guess without seeing the code though. – G.M. Apr 20 '20 at 12:10
  • @G.M. there is no chance to see the code, because it is completely system call stack. – Dmitriano Apr 20 '20 at 15:33
  • 1
    Edit: I am having exactly the same problem on two of our apps. I have one app build with Qt 5.14.2 and one with 5.13.2 and both have the same "in abort" crash. Both apps are set to target SDK 28 (Android 9). We are now investigating. Would be cool if you update your findings here - I'll do the same – Michael Apr 22 '20 at 16:55
  • @Michael my app also targets SDK 28 (Android 9) and the app versions built with QT 5.14.2 and 5.14.1 have this crash on Android 10. – Dmitriano Apr 24 '20 at 12:51
  • @G.M. Looks like your guess was correct, I did a small test, see https://developernote.com/2020/04/qt-app-crashes-at-the-destructor-of-std-thread-on-android-10/ – Dmitriano Apr 25 '20 at 11:29
  • @Michael Looks like `std::thread` object is destroyed at a wrong place, but it is not clear where and why, see my small experiments https://developernote.com/2020/04/qt-app-crashes-at-the-destructor-of-std-thread-on-android-10/ – Dmitriano Apr 25 '20 at 11:30
  • 1
    Try looking for an uncaught/unhandled exception somewhere that's causing the call stack to be unwound unexpectedly. – G.M. Apr 25 '20 at 12:08
  • 1
    It's an outside chance, but I figured out a while back that on any call into the JVM through JNI, you have to make sure that if an exception occurred during your call and doesn't get caught and handled on the JVM side, that you clear it via JNI. So, after every call into the JVM, I run this code: QAndroidJniEnvironment env; if (env->ExceptionCheck()) { \ env->ExceptionDescribe(); \ env->ExceptionClear(); \ } That cleared up some mysterious crashes for me. – David K. Hess Apr 28 '20 at 02:10

1 Answers1

1

We've just released an update for one of our games and it looks as if the crash is fixed. This is what we did: Android 10 and Android 9 show a different default behaviour when using the Android back button. On Android 10 the app closes but on the console output I see the app being stuck in a loop for about 5 seconds before it really quits. This does not happen on Android 9. This is the output I get on an Android 10 device when I hit the back button and the app closes:

....
05-04 18:26:21.315 26882 26908 I nkeycat.tendow:
I nkeycat.tendow: QarthPatchMonintor::CheckNotifyEvent
05-04 18:26:21.315 26882 26908 I nkeycat.tendow:
I nkeycat.tendow: QarthPatchMonintor::CheckNotifyEvent before read
05-04 18:26:21.315 26882 26908 I nkeycat.tendow:
I nkeycat.tendow: QarthPatchMonintor::CheckNotifyEvent after read, length = -1
05-04 18:26:21.315 26882 26908 I nkeycat.tendow:
I nkeycat.tendow: QarthPatchMonintor::CheckNotifyEvent
05-04 18:26:21.315 26882 26908 I
...

I am now catching the Android back button everywhere In QML and when the user really wants to quit the app, I call the following custom Java function to quit gracefully:

public String quitApp() { // Qt C++ call

    try {
        finishAffinity();
        System.exit(0);

    } catch (Exception exc) {
        exc.printStackTrace();
        logException(exc);
    }
    return "";
}

We have also implemented the what David K. Hess suggested.

Michael
  • 176
  • 1
  • 8
  • On `Android 10` Back button has the same wrong behavior as deactivating the app with a swipe in Gesture mode, see https://developernote.com/2020/05/qt-app-is-deactivated-incorrectly-on-android-10-in-gesture-mode/ for details. Briefly, `aboutToQuit` is called when the app is deactivated, but `onApplicationStateChanged` (where my game is saved) is not. I published a new app version with a quick workaround described here https://developernote.com/2020/05/qt-app-is-deactivated-incorrectly-on-android-10-in-gesture-mode/#workaround and David K's changes, will see what will happen with it. – Dmitriano May 06 '20 at 13:23
  • Are you sure that calling `System.exit(0)` is a good idea? Why not to call `finishAndRemoveTask()`? See https://stackoverflow.com/questions/6330200/how-to-quit-android-application-programmatically – Dmitriano May 16 '20 at 12:31
  • reported this as a QT bug, see https://bugreports.qt.io/browse/QTBUG-85449 – Dmitriano Jul 06 '20 at 13:26