Open SpookyUndefined opened 2 years ago
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.
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)
trying to look for a more recent occurrence of this issue keeps bringing me back to this thread/issue so wanted to chime in:
apk v1.17.0 running on android 14 is crashing for me when resumed from background, noticed specifically in the ppsspp core, on a pixel 8 pro even with threaded video disabled.
@SpookyUndefined Please rename the issue title to something like RetroArch crashes when game resumed from background and video threaded is enabled
Don't know if implementing AAudio or Oboe audio driver will help to fix this issue.
OK, for the next stable version, Threaded Video will be disabled by default for Android.
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.
Still crashing on S23 Ultra OneUI 6.1 even with threaded video off
For PSP games I still would suggest you use the standalone PPSSPP application, as it works with less performance overhead than the core in RetroArch and it doesn't suffer from those crashes. Also, for achievements there's the latest nightly, it works wonders. Also I haven't experienced any crashes on any other core since I disabled Threaded Video.
As mentionned by @AGulev, attaching the native thread to a JVM thread through AttachCurrentThread before calling egl_destroy
should fix the issue.
It was fixed in AOSP somewhere down the road between android-13.0.0-r8 and android-13.0.0-r16, with the commit 7309b4f - BBQ: Attach calling thread to jvm if needed
As mentionned by @AGulev, attaching the native thread to a JVM thread through AttachCurrentThread before calling
egl_destroy
should fix the issue.It was fixed in AOSP somewhere down the road between android-13.0.0-r8 and android-13.0.0-r16, with the commit 7309b4f - BBQ: Attach calling thread to jvm if needed
Yes, it was an issue in a few versions of Android 13 (was confirmed by Android Team) and we had to make this patch in the game engine to make sure games made with Defold works stable on all the versions.
We use this workaround for the same crash https://github.com/defold/defold/pull/7014/files Maybe it will be helpful for you
Wanted to confirm this is still happening for me on multiple devices and android versions when using either mupen64 core with the latest nightly and stable builds. Threaded video disabled does not fix it.
Edit: found duplicate issue @https://github.com/libretro/RetroArch/issues/15275#issue-1705482028
Just chiming in because there's the possibility someone has the same issue as I had.
I started having this issue a few months ago on a chinese handheld running Android 11 (T618 chipset). Since I found this issue open plus a few people complaining on reddit, I just assumed this was a Retroarch problem that was eventually going to be fixed. As time went on without a fix, I decided to try some troubleshooting again and found out that it was actually the launcher I was using.
I used to run Daijishõ, but since the ability to view RetroAchievements on the frontend UI is broken, I decided to finally set up Pegasus.
Pegasus offers an "Android Metadata Generation" tool that streamlines the set up process of the launcher, which, while very powerful and granular, is also very much manual. Thing is, the output of the metadata generator includes the launch arguments:
-e QUITFOCUS
--activity-clear-task
--activity-clear-top
--activity-no-history"
That makes Retroarch very touchy, and any minimal sign of it not being the active application forces the core to restart the content.
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
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