Closed pinumbernumber closed 10 years ago
More reports of crashing -
https://twitter.com/akosichoi/status/433425910377615361
@Themaister - please take a look at this if you can. It seems to be a really serious issue.
Also pinumbernumber - please get us a stack trace of exactly where it crashes right now.
Okay, I have induced this on desktop (Win64). Here follows output from thread apply all backtrace
:
Thread 7 (Thread 4356.0xbec):
#0 0x0000000076f70591 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x0000000077017f48 in ntdll!DbgUiRemoteBreakin () from C:\Windows\SYSTEM32\ntdll.dll
#2 0x0000000000000000 in ?? ()
Thread 6 (Thread 4356.0x1c74):
#0 0x000007fef486810a in xaudio2!DllUnregisterServer () from C:\Windows\system32\XAudio2_7.dll
#1 0x0000000006901b00 in ?? ()
#2 0x000007fef48a237e in xaudio2!DllUnregisterServer () from C:\Windows\system32\XAudio2_7.dll
#3 0x0000000000000000 in ?? ()
Thread 5 (Thread 4356.0x1298):
#0 0x0000000076f7186a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x000007fefd431430 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2 0x0000000000000001 in ?? ()
#3 0x0000000000000001 in ?? ()
#4 0x0000000000000000 in ?? ()
Thread 4 (Thread 4356.0xd30):
#0 0x0000000076f712fa in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x000007fefd4310dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2 0x0000000000000000 in ?? ()
Thread 3 (Thread 4356.0x1bd0):
#0 0x0000000076f7186a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x0000000076f3b037 in ntdll!TpIsTimerSet () from C:\Windows\SYSTEM32\ntdll.dll
#2 0x0000000000000002 in ?? ()
#3 0x0000000000000000 in ?? ()
Thread 2 (Thread 4356.0x1a0c):
#0 0x0000000076f712fa in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x000007fefd4310dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2 0xffffffffffffffff in ?? ()
#3 0xffffffffffffffff in ?? ()
#4 0xffffffffffffffff in ?? ()
#5 0x0000000003260de8 in ?? ()
#6 0x0000000000000000 in ?? ()
Thread 1 (Thread 4356.0x1890):
#0 0x0000000076f712fa in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1 0x000007fefd4310dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2 0x00000000002fff10 in ?? ()
#3 0x00000000004440fd in slock_unlock (lock=0xd3b620) at thread.c:129
#4 0x0000000000444c4a in thread_wait_reply (thr=0xd3adf0, cmd=CMD_OVERLAY_SET_ALPHA)
at gfx/video_thread_wrapper.c:363
#5 0x00000000004456bd in thread_overlay_set_alpha (data=0xd3adf0, index=0, mod=0.699999988)
at gfx/video_thread_wrapper.c:632
#6 0x0000000000426b59 in input_overlay_set_alpha_mod (ol=0x309800, mod=0.699999988) at input/overlay.c:823
#7 0x0000000000426968 in input_overlay_poll_clear (ol=0x309800) at input/overlay.c:774
#8 0x00000000004032cc in input_poll_overlay () at retroarch.c:591
#9 0x0000000000403311 in rarch_input_poll () at retroarch.c:601
#10 0x00000000698cce40 in retro_run () from C:\Games\RetroArch_install\cores\nestopia_libretro.dll
#11 0x000000000000002f in ?? ()
#12 0x0100000000000018 in ?? ()
#13 0x0000000000000000 in ?? ()
Thanks. That makes it much easier to track down. Well, now I get why normalized overlays were slow ... set_alpha blocks on frame completion instead of non-blocking. No wonder. v_v Can't even use fast-forward in that case.
Non-normalized overlays would never call set_alpha to begin with.
EDIT: I pushed a commit which should bump up the performance quite a bit with threaded video + normalized overlays. Should hopefully fix that ANR as well.
That seems to have fixed it, thanks! It was intermittent so I'll test a while longer on win64, and I'll try to get it built for Android so I can test that. Fast-forward works now too.
Tested plenty on Android, I'm certain it's fixed. Thanks again
Very cool. Thanks a lot for the backtrace pinumbernumber and thanks to maister for fixing it.
[Version currently on the Play Store, I'm working on getting an android buildenv set up to test master]
Forum thread
Tested on both Nexus 4 and Nexus 7 2012. Anecdotally, opening RGUI (ever during the run) seems to cause it to happen sooner. It also seems to happen very often when resetting the core.
Its slow/inconsistent triggering and relation to threading suggests a deadlock-inducing race condition particular to Android.
An old version did not exhibit this, unfortunately I don't know what version that was. If I get a proper build environment set up I'll do some hunting for the breaking change(s).