search

devmiyax / yabause

Yabause is a Sega Saturn emulator and took over as Yaba Sanshiro
http://www.uoyabause.org
GNU General Public License v2.0
210 stars 35 forks source link

Fighting Vipers no longer works, black screen. #795

Closed Cee123 closed 2 years ago

Cee123 commented 3 years ago

The game Fighting Vipers no longer works on the latest Yaba Sanshiro and loads to a black screen. Tried Dynared and Interpreter. Makes no difference.

Kelvfimer commented 2 years ago

Hello

I read this issue and it sounded the same as the one I experienced on Cotton 2 https://github.com/devmiyax/yabause/issues/849 .

I ran Fighting Vipers on yabasanshiro stand alone on emulec odroid n2+ . I get the black screen. When attaching GDB, it pops up the same call stack. It didn't go ahead because of YabWaitEventQueue line value = queue->buffer[queue->out] (yabause/src/thr-linux.cpp:235) is waiting at the FUTEX

(gdb) bt

0 futex_wait_cancelable (private=0, expected=0, futex_word=0x28ae7090)

at ../sysdeps/nptl/futex-internal.h:183

1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x28ae7008,

cond=0x28ae7068) at pthread_cond_wait.c:508

2 __pthread_cond_wait (cond=cond@entry=0x28ae7068,

mutex=mutex@entry=0x28ae7008) at pthread_cond_wait.c:638

3 0x000000000067b8c8 in YabWaitEventQueue (queue_t=0x28ae6ff0)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/thr-linux.cpp:235

4 0x000000000060243c in YabauseEmulate ()

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/yabause.c:791

5 0x0000000000601f00 in YabauseExec ()

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/yabause.c:588

6 0x000000000053fde8 in main (argc=, argv=)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/retro_arena/main.cpp:652
Kelvfimer commented 2 years ago

I think the issue is a deadlock because of the futex

I see the trhead 69 is also having a futex on same procedure. This time is called from yabause/src/vdp2.cpp:515

(gdb) where

0 futex_wait_cancelable (private=0, expected=0, futex_word=0x28cbb744)

at ../sysdeps/nptl/futex-internal.h:183

1 __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x28cbb6b8,

cond=0x28cbb718) at pthread_cond_wait.c:508

2 __pthread_cond_wait (cond=cond@entry=0x28cbb718,

mutex=mutex@entry=0x28cbb6b8) at pthread_cond_wait.c:638

3 0x000000000067b8c8 in YabWaitEventQueue (queue_t=0x28cbb6a0)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/thr-linux.cpp:235

4 0x00000000005b0d3c in VdpProc (arg=)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/vdp2.cpp:515

5 VdpProc (arg=)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/vdp2.cpp:500

6 0x0000007fa67d5dd4 in start_thread (arg=0x7fca922ab0)

at pthread_create.c:463

7 0x0000007fa3f2879c in thread_start ()

at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

(gdb)

(gdb) info threads Id Target Id Frame 1 Thread 0x7fa6852010 (LWP 5519) "yabasanshiro" futex_wait_cancelable ( private=0, expected=0, futex_word=0x28ae7090) at ../sysdeps/nptl/futex-internal.h:183 2 Thread 0x7fa38c4130 (LWP 5523) "SDLHotplugALSA" 0x0000007fa3ef7d8c in GI_clock_nanosleep (clock_id=, clock_id@entry=0, flags=flags@entry=0, req=0x7fa38c3770, rem=0x7fa38c3760) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:46 3 Thread 0x7fa30c3130 (LWP 5525) "mali-mem-purge" 0x0000007fa3ef7d8c in GI_clock_nanosleep (clock_id=, clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fa30c2800, rem=rem@entry=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:46 4 Thread 0x7fa28c2130 (LWP 5526) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d53030) at ../sysdeps/nptl/futex-internal.h:320 5 Thread 0x7fa20c1130 (LWP 5527) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d530c8) at ../sysdeps/nptl/futex-internal.h:320 6 Thread 0x7fa18c0130 (LWP 5528) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d53160) at ../sysdeps/nptl/futex-internal.h:320 7 Thread 0x7fa10bf130 (LWP 5529) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d531f8) --Type for more, q to quit, c to continue without paging-- at ../sysdeps/nptl/futex-internal.h:320 8 Thread 0x7fa08be130 (LWP 5530) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d53290) at ../sysdeps/nptl/futex-internal.h:320 9 Thread 0x7f9bfff130 (LWP 5531) "mali-utility-wo" futex_abstimed_wait_cancelable (private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x27d53328) at ../sysdeps/nptl/futex-internal.h:320 10 Thread 0x7f9b7fe130 (LWP 5532) "mali-cmar-backe" 0x0000007fa3f1f760 in __GI___poll (fds=0x7f9b7fd770, nfds=4, timeout=) at ../sysdeps/unix/sysv/linux/poll.c:41

Kelvfimer commented 2 years ago

Reading further it seems that the lock is done in thread 70 on /yabause/src/vidogl.c:3536 YabThreadLock(g_rotate_mtx); (same procedure appears on coton 2 issue https://github.com/devmiyax/yabause/issues/849

(gdb) bt

0 __lll_lock_wait (futex=futex@entry=0x7f745976f0, private=0) at lowlevellock.c:52

1 0x0000007fa4a4ac70 in __GI___pthread_mutex_lock (mutex=0x7f745976f0) at pthread_mutex_lock.c:80

2 0x00000000005cc75c in Vdp2DrawRotationThread (p=0x0)

at /home/kelv/EmuELEC/build.EmuELEC-Amlogic-ng.aarch64-4/build/yabasanshiroSA-f6f41dd6485c638ab661f3acd2951c9522f34450/yabause/src/vidogl.c:3536

3 0x0000007fa4a48dd4 in start_thread (arg=0x7f7d7dd620) at pthread_create.c:463

4 0x0000007fa219b79c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

(gdb) x /3d 0x7f745976f0 0x7f745976f0: 2 0 6283 (gdb)

Kelvfimer commented 2 years ago

Hello on branch 1.9.0 it already works!!! Thx

Cee123 commented 2 years ago

Hello on branch 1.9.0 it already works!!! Thx

Ah wow, really? Thanks for letting me know. I don't know why I wasn't notified of your earlier responses to this bug/issue. I had actually posted a couple of issues here but received no response or acknowledgment from the official developer, so I had just forgotten about them.

devmiyax commented 2 years ago

@Kelvfimer @Cee123 Actually pi4-1-9-0 branch increases compatibility, but it's 20% slower than the pi4 branch. I'm investigating it.