[Bug] SCUMMVM hangs on boot / freezes RA

[SupervisedThinking]

Well I've experienced the same hangs as people do here https://forums.libretro.com/t/lakka-scummvm-hanging/34063 and here https://nitter.nixnet.services/IlSentenziatore/status/1409218044560384002#m so I gave the updated version a try https://github.com/diablodiab/scummvm but still failes to run.

You can find a trace output here https://github.com/diablodiab/scummvm/issues/2#issuecomment-889123774 the behaviour is the same for his v2.3 and for libretro v2.1.1

This only happens when I try to run SCUMMVM on my Arm SBC, a RK3399, my Generic Build is fine. Also if you use the buildbot provided core built in 202008 it works fine. Since Lakka 3.2 & latest LibreELEC master fail to build a working core it might be related to some recent changes?

[ToKe79]

I tried building the core for Lakka RPi4.arm with older commit (7b1e9299057a01a1defad6dbae4bdbeed36aa767), the behavior is same.

logs with latest (63e57573a9ffe71a1083ff46d9cd210203b87afb) version of the core

backtrace in gdb showed:

Thread 1 "retroarch" received signal SIGINT, Interrupt. <-- this is me pressing ctrl-c when the core hung
__GI___nanosleep (remaining=0x0, requested_time=0x244ca60) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28      ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) bt
#0  __GI___nanosleep (remaining=0x0, requested_time=0x244ca60) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
#1  __GI___nanosleep (requested_time=0x244ca60, remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0xb1f478d8 in OSystem_RETRO::delayMillis(unsigned int) () from /tmp/cores/scummvm_libretro.so
#3  0xb3bc4a0c in GUI::GuiManager::runLoop() () from /tmp/cores/scummvm_libretro.so
#4  0xb3bc1664 in GUI::Dialog::runModal() () from /tmp/cores/scummvm_libretro.so
#5  0xb1f4acfc in launcherDialog() () from /tmp/cores/scummvm_libretro.so
#6  0xb1f4d058 in scummvm_main () from /tmp/cores/scummvm_libretro.so
#7  0xb1f44d48 in retro_wrap_emulator() () from /tmp/cores/scummvm_libretro.so
#8  0xb1f45e04 in retro_run () from /tmp/cores/scummvm_libretro.so
#9  0x726f6320 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

strace (excerpt):

nanosleep({tv_sec=0, tv_nsec=1000000}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=109227}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=109314}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=109408}, NULL) = 0
nanosleep({tv_sec=0, tv_nsec=1000000}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=110636}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=3725, tv_nsec=461580908}) = 0
futex(0x2063214, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x20e0288, FUTEX_WAKE_PRIVATE, 1) = 1
clock_gettime(CLOCK_MONOTONIC, {tv_sec=3725, tv_nsec=462288585}) = 0
clock_gettime(CLOCK_MONOTONIC, {tv_sec=3725, tv_nsec=462394751}) = 0
poll([{fd=13, events=POLLIN}], 1, 0)    = 0 (Timeout)
poll([{fd=11, events=POLLIN}], 1, 0)    = 0 (Timeout)
epoll_wait(12, [], 32, 0)               = 0
_newselect(28, [27], NULL, NULL, {tv_sec=0, tv_usec=0}) = 0 (Timeout)
gettimeofday({tv_sec=1637191182, tv_usec=112158}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=112248}, NULL) = 0
gettimeofday({tv_sec=1637191182, tv_usec=112335}, NULL) = 0
nanosleep({tv_sec=1077936128, tv_nsec=0}, NULL) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) <-- me pressing ctrl-c after hanging
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
sigreturn({mask=[]})                    = -1 EINTR (Interrupted system call)
gettimeofday({tv_sec=1637191187, tv_usec=640286}, NULL) = 0

When I ran strace with output to stderr, the hanging was on:

nanosleep({tv_sec=1077936128, tv_nsec=0}, 

I'm no expert, but hopefully someone can figure this out?

[ToKe79]

Just read man nanosleep:

           struct timespec {
               time_t tv_sec;        /* seconds */
               long   tv_nsec;       /* nanoseconds */
           };

so a call to sleep for 1077936128 seconds was made? maybe some integer overflow or wrong parameter used?

[ssj17vegeta]

Can confirm with the exact same problem

[mrfixit2001]

This problem is because of retro_sleep in retroarch. I don't think isn't being defined correctly for all platforms.

For now I've worked around this issue by patching the core to use usleep.

[SupervisedThinking]

@mrfixit2001 mind to share you patch?

[mrfixit2001]

@SupervisedThinking sure - but it's written to apply to the updated fork by diablodiab. Not sure if it will apply to this without modification.

MRFIXIT: Fix the freeze up when loading the game
--- a/backends/platform/libretro/libretro_os.cpp
+++ b/backends/platform/libretro/libretro_os.cpp
@@ -722,7 +722,7 @@
                    if (time_remaining > elapsed_time)
                    {
                        time_remaining = time_remaining - elapsed_time;
-                       retro_sleep(1);
+                       usleep(1000);
                    }
                    else
                    {
@@ -739,7 +739,7 @@
                // Use accurate method...
                while(getMillis() < start_time + msecs)
                {
-                   retro_sleep(1);
+                   usleep(1000);
                    retroCheckThread();
                    // Have to handle the timer manager here, since some engines
                    // (e.g. dreamweb) sit in a delayMillis() loop waiting for a

[SupervisedThinking]

@mrfixit2001 mind to PR your fix? Works for me on my Vim3 (A311D) - I guess it's related to some gcc/arm/quirk that the time is not set correctly

[mrfixit2001]

@SupervisedThinking thanks for testing! It's definitely an ARM thing. I'm going to be submitting to diablodiab to help encourage libretro maintainers to pull his updates :) I am working on a fix for a COMI game failure as well to hopefully have submitted with it.

[SupervisedThinking]

@mrfixit2001 np - well it's a thing that bothered me for a while now, I'm pretty sure it occured after the gcc10 bump of base(LibreELEC) and this would explain why it works/worked for lakka since they still use gcc9 IIRC