RetroArch
RetroArch copied to clipboard
RetroArch crashes when game resumed from background
Description
Whenever RetroArch is put into the background and then resumed while a game is active, it crashes
Expected behavior
Game remains paused until app is resumed
Actual behavior
RetroArch crashes
Steps to reproduce the bug
- Load any core
- Load any game
- Put RetroArch in the background (Home button, open another application, etc)
- Return to RetroArch
Bisect Results
Started immediately after installing
Version/Commit
Tested on all of the following versions: -RetroArch Plus (Google Play Store, 1.9.12 (2021-11-03)) -RetroArch Stable (1.10.3) -RetroArch Nightly (2022-07-23)
Environment information
- OS: OxygenOS 11 (Android 11)
PRs welcome.
Any cores in particular? And tried with a fresh config file?
Just tried latest RA nightly and FCEUmm, ParaLLEl, PCSX ReARMed, mGBA, Snes9x, Genesis Plus GX and Flycast cores, switching resumes fine for me. However my phone is a bit old and I'm using an older version of Android (7 I believe 😅 ) so maybe that's why it works for me...
Testing with an Android OS version other than OxygenOs is likely not enough to reproduce the problem. For instance, the issue does not happen on either a Galaxy S4, S10 plus or a S22 Ultra
@SpookyUndefined May you try to get some log with something like pidcat or logcat ?
Using something like
pidcat com.retroarch (RetroArch) or pidcat com.retroarch.aarch64 (RetroArch Plus)
Or use something like Logcat Reader Play Store | Logcat Reader F-Droid.
Thank you.
I can confirm this issue with a Pixel 4a and Android 13.
Also confirmed here: https://forums.libretro.com/t/retroarch-keeps-crashing-on-pixel-6-android-13/38693
Same issue on pixel 6a, using reteoarch plus. Open retroarch, Switch off/on and retroarch crash, same thing when switching to another app
Having the same issue with Android 13 on Pixel 5a.
- Launch Retroarch
- While playing a game or in menu, lock screen or switch apps
- RetroArch crashes when focused/screen is unlocked
Problem occurs with RetroArch and RetroArch Plus from the Play Store (1.9.12), as well as fresh installs of the latest stable (1.10.3) and nightly (August 26 2022) builds.
I previously had this same issue after an Android 12 security update, but was able to fix it by setting the app's battery usage to Unrestricted. That isn't working since the 13 update.
PRs welcome.
I don't get any of these issues on a Samsung Galaxy S4, S10 Plus, and an S22 Ultra. So I dunno what you want me to do.
Find an Android coder who does get these issues, who can program in C/C++, get him to figure out the issue, find a fix for it, and submit a PR. That's the only way this is going to get fixed.
I also confirm that this started happening with an upgrade to Android 13 on Pixel 6.
I was able to reproduce this in an Android emulator using SDK33 on a virtual Pixel 5. Unfortunately, the stacktrace doesn't provide anything useful (to me).
art_sigsegv_fault 0x000079f80e492e90
art::FaultManager::HandleFault(int, siginfo*, void*) 0x000079f80e4933b5
art::SignalChain::Handler(int, siginfo*, void*) 0x000079fab55cdfcc
__restore_rt 0x000079faae32bb90
std::__1::__function::__func<android::nativeSetTransactionHangCallback(_JNIEnv*, _jclass*, long, _jobject*)::$_1, std::__1::allocator<android::nativeSetTransactionHangCallback(_JNIEnv*, _jclass*, long, _jobject*)::$_1>, void (bool)>::destroy_deallocate() 0x000079fac2d832f4
android::BLASTBufferQueue::~BLASTBufferQueue() 0x000079fab2ee4aa7
android::BLASTBufferQueue::~BLASTBufferQueue() 0x000079fab2ee49e0
android::RefBase::decStrong(void const*) const 0x000079f7e875725a
Looking through the other threads, I did find these stacktraces in the RetroArch code. Maybe they'll mean something to someone with more Android experience.
syscall 0x000079faae32bd58
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*) 0x000079faae3303d3
pthread_cond_wait 0x000079faae39c053
scond_wait rthreads.c:715
video_thread_wait_reply video_thread_wrapper.c:80
video_thread_send_and_wait_user_to_thread video_thread_wrapper.c:92
video_thread_free video_thread_wrapper.c:822
video_driver_free_internal video_driver.c:1545
driver_uninit driver.c:765
video_driver_reinit_context video_driver.c:4159
video_driver_reinit video_driver.c:4176
command_event_reinit command.c:1767
command_event retroarch.c:2008
android_input_poll android_input.c:1495
input_driver_poll input_driver.c:4054
runloop_check_state runloop.c:6979
runloop_iterate runloop.c:7676
rarch_main retroarch.c:3860
android_app_entry platform_unix.c:456
thread_wrap rthreads.c:143
__pthread_start(void*) 0x000079faae39ccbb
__start_thread 0x000079faae330cc8
syscall 0x000079faae32bd58
__futex_wait_ex(void volatile*, bool, int, bool, timespec const*) 0x000079faae3303d3
pthread_cond_wait 0x000079faae39c053
scond_wait rthreads.c:715
android_app_set_window platform_unix.c:275
onNativeWindowCreated platform_unix.c:388
android::onSurfaceCreated_native(_JNIEnv*, _jobject*, long, _jobject*) 0x000079fac2d23bba
art_jni_trampoline 0x000000007264e236
nterp_helper 0x000079f80e369d7c
nterp_helper 0x000079f80e36a422
OK, I ordered a Google Pixel 6 Pro so that I can hopefully reproduce and solve this.
I've noticed so far the issue does not happen when Threaded video is disabled. Can you confirm this over on your end @SpookyUndefined ?
I can confirm that disabling Threaded Video prevents the issue on my Pixel 6.
The text description for the setting says "Use only if full speed cannot be obtained otherwise", but the default is enabled for android: https://github.com/libretro/RetroArch/blob/ce8389d4a6825dd99545d47d252936771bde0f53/config.def.h#L384-L391
It looks like the default was changed some time ago (https://github.com/libretro/RetroArch/commit/212ff42ae073d73dcf2ee08c1b72c9ba77d09abb), but without a PR or anything else that would indicate why.
It was defaulted to ON on Android due to that platform's generally unpredictable/bad sync. It was nearly impossible to get non-crackly audio back then. That may have changed, though.
I can also confirm that disabling Threaded Video prevents the issue on my Pixel 4a.
PRs welcome.
I don't get any of these issues on a Samsung Galaxy S4, S10 Plus, and an S22 Ultra. So I dunno what you want me to do.
Find an Android coder who does get these issues, who can program in C/C++, get him to figure out the issue, find a fix for it, and submit a PR. That's the only way this is going to get fixed.
I have a Galaxy S22 Ultra Exynos with OneUI Beta 2 and my phone got the same issue. Even without a open core, the app crashes on resume. I will try, if disabling threaded video, will do it.
Yes it does, when I disable threaded video, screen went for a short amount of time black and then it resumed as I would expect it from every other android app.
PRs welcome.
I don't get any of these issues on a Samsung Galaxy S4, S10 Plus, and an S22 Ultra. So I dunno what you want me to do.
Find an Android coder who does get these issues, who can program in C/C++, get him to figure out the issue, find a fix for it, and submit a PR. That's the only way this is going to get fixed.
We (in Defold) found this issue is reproducible only on Android 13. I'll let you know when I know more (I'm investigating it now)
I can't reproduce our issue using the latest android 13 version (QPR1) https://developer.android.com/about/versions/13/get-qpr
Disabling threaded video worked for my Pixel 6 running GrapheneOS version TP1A.221005.002.2022102300 (Android 13). Thank you for finding the workaround!!
Pixel 7 Pro here. Crashes upon switching apps and will often make the phone unresponsive when switching back into the app. I will try disabling threaded video and report back.
Edit: Settings > Video > Toggle Threaded Video to Off > Save Current Config.
It worked! Thanks for the workaround.
We use this workaround for the same crash https://github.com/defold/defold/pull/7014/files Maybe it will be helpful for you
Also stopping by to say that disabling threaded video fixed the issue on my Pixel 7 Pro.
OK, for the next stable version, Threaded Video will be disabled by default for Android.
https://github.com/libretro/RetroArch/commit/63a080af3f87f2ca959f4d4c277adebb422d5c94
Not a real solution to the problem but will indirectly prevent this from happening when left disabled. Plus it seems Android scheduling these days is good enough that non-threaded video is feasible - previously threaded video was necessary cuz of how variable frametimes were, but this was observed around 2013. Lots have probably changed since then, plus threaded video has a bit more latency. So hopefully overall it's a win.
Pixel 7 here. Crashes as described and threaded video disable works as a work around. Thanks all who already figured this out!
This still happens with Pixel 7 Pro with Threaded Video set to off only on PPSSPP core.
This still happens with Pixel 7 Pro with Threaded Video set to off only on PPSSPP core.
I am having this problem on Oppo Find X3 Neo. It happens on both PPSSPP and Mupen64
Confirmed disabling the Threaded Video worked on Nothing Phone (2). Android 13 with Snapdragon 8+ Gen 1.
Activating bilinear filtering and deactivating threaded vidéo fixed it for me
Hello, Motorola E13 here. I can confirm that enabling Threaded video makes RetroArch crash as soon as you leave the app and come back to it. Disabled the option, the issue went away here.
It's still crashing for me even when Threaded Video is set to off... (Xiaomi Poco X3 Pro)