libretro / RetroArch

Cross-platform, sophisticated frontend for the libretro API. Licensed GPLv3.
http://www.libretro.com
GNU General Public License v3.0
10.09k stars 1.81k forks source link

RetroArch crashes when game resumed from background #14209

Open SpookyUndefined opened 2 years ago

SpookyUndefined commented 2 years ago

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

  1. Load any core
  2. Load any game
  3. Put RetroArch in the background (Home button, open another application, etc)
  4. 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

LibretroAdmin commented 2 years ago

PRs welcome.

bslenul commented 2 years ago

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

LibretroAdmin commented 2 years ago

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

gouchi commented 2 years ago

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

aus-m commented 2 years ago

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

fonkfader commented 2 years ago

Same issue on pixel 6a, using reteoarch plus. Open retroarch, Switch off/on and retroarch crash, same thing when switching to another app

artfrance commented 2 years ago

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.

LibretroAdmin commented 2 years ago

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.

Jamiras commented 2 years ago

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
LibretroAdmin commented 2 years ago

OK, I ordered a Google Pixel 6 Pro so that I can hopefully reproduce and solve this.

LibretroAdmin commented 2 years ago

I've noticed so far the issue does not happen when Threaded video is disabled. Can you confirm this over on your end @SpookyUndefined ?

Jamiras commented 2 years ago

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.

hizzlekizzle commented 2 years ago

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.

aus-m commented 2 years ago

I can also confirm that disabling Threaded Video prevents the issue on my Pixel 4a.

christianmende commented 1 year ago

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.

christianmende commented 1 year ago

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.

AGulev commented 1 year ago

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)

AGulev commented 1 year ago

I can't reproduce our issue using the latest android 13 version (QPR1) https://developer.android.com/about/versions/13/get-qpr

GeoffChurch commented 1 year ago

Disabling threaded video worked for my Pixel 6 running GrapheneOS version TP1A.221005.002.2022102300 (Android 13). Thank you for finding the workaround!!

nullNOVA commented 1 year ago

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.

AGulev commented 1 year ago

We use this workaround for the same crash https://github.com/defold/defold/pull/7014/files Maybe it will be helpful for you

ChristoWolf commented 1 year ago

Also stopping by to say that disabling threaded video fixed the issue on my Pixel 7 Pro.

LibretroAdmin commented 1 year ago

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.

HarleyLorenzo commented 1 year ago

Pixel 7 here. Crashes as described and threaded video disable works as a work around. Thanks all who already figured this out!

Tedris commented 1 year ago

This still happens with Pixel 7 Pro with Threaded Video set to off only on PPSSPP core.

SamTees commented 1 year ago

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

TdZink commented 1 year ago

Confirmed disabling the Threaded Video worked on Nothing Phone (2). Android 13 with Snapdragon 8+ Gen 1.

oddsito commented 7 months ago

Activating bilinear filtering and deactivating threaded vidéo fixed it for me

clorophilla commented 6 months ago

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.

BoardAnims commented 5 months ago

It's still crashing for me even when Threaded Video is set to off... (Xiaomi Poco X3 Pro)

AdmiralShinysides commented 5 months ago

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.

gouchi commented 5 months ago

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

dpkg-i-foo-deb commented 4 months ago

OK, for the next stable version, Threaded Video will be disabled by default for Android.

63a080a

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

clorophilla commented 4 months ago

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.

solevic commented 4 months ago

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

AGulev commented 4 months ago

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

Kionea commented 3 months ago

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

icynicx commented 3 months ago

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.

TL;DR: If you use Pegasus Launcher for Android, remove the launch arguments listed above from your metadata.pegasus.txt or equivalent file(s).