RetroArch causes malfunction in some games running ScummVM core

[ner00]

Description

At the moment I have only tested this on Windows, unsure if this is a cross-platform issue.
Some ScummVM games will work incorrectly when run through retroarch.exe, but curiously will work fine when run through retroarch_debug.exe.

While searching for mentions to this bug I found the first instance back in June 2019, in the libretro forum: https://forums.libretro.com/t/scummvm-problem/22828 - and in scummvm core repo it was mentioned in February 2020: https://github.com/libretro/scummvm/issues/158

Because the games affected work with the debug executable and not with the standard executable, maybe the issue is triggered by RetroArch and not the core. While not all the games mentioned in the scummvm repo issue may share the same root, at the very least Beneath a Steel Sky is an indication that RetroArch may be one factor.

Expected behavior

Games should work as expected with the standard retroarch.exe, instead they only work with retroarch_debug.exe.

Actual behavior

A few games will either crash RetroArch or get stuck in a black screen after the game uses a fadeout transition effect, but only when using retroarch.exe, this does not happen if the games are ran with retroarch_debug.exe.

Steps to reproduce the bug

A simple example is the game Beneath a Steel Sky, which shows this behavior in three occasions, one of which makes it unplayable.

1. Run the ScummVM game Beneath a Steel Sky using retroarch.exe (either frontend or command line, it has no bearing).
2. The Virgin logo should fade out and be followed by the Revolution logo, then the intro, but here instead everything will unfold in pitch black (only audio) until the game starts.
3. After the game starts, go down the stairs, the player gets shot and a fade out should transition to the gameover screen, instead everything will go black.
4. Replay the last step, but instead of going down the stairs pick up the metal bar stuck on the left wall and use it on the right door. As soon as you unlock that door and go through it, the game should fade out and into the next room; here again instead of the fade out the game will go pitch black while still being "playable" insofar as that the cursor and objects text will be visible but the game will be essentially unplayable.

Repeat the steps above, but running retroarch_debug.exe instead, there shouldn't be any issue this time around.

In case you don't have retroarch_debug.exe and need it, grab it here (x64, v1.90 [6388872])

Bisect Results

I have downloaded and tested this with clean Windows versions of RetroArch, with no customization whatsoever, the issue persists. Seems to have been present since mid-2019 at the very least, but could have been there for longer. I've tested an older version, RetroArch v1.7.2 (023e280) (x64), this issue does not happen at all. Older version I was able to test where this issue is present is v1.8.5

Additional games affected

• Beneath a Steel Sky
• Bud Tucker in Double Trouble
• Drascula - The Vampire Strikes Back
• Gobliins 2
• Goblins 3
• Legend of Kyrandia, The - Malcolm’s Revenge (affects intro / FMV sequences)
• Leisure Suit Larry 7 - Love for Sail
• Toonstruck
• Touche
• Woodruff and the Schnibble of Azimut

Version/Commit

• RetroArch: 1.9.0/5e551dd92b
• RetroArch: 1.9.10/ebe0d89d

Environment information

• OS: Win10 20H2
• OS: Win10 21H1

[ner00]

Adding another one to the list: Bud Tucker in Double Trouble
This one is entirely unplayable, only the intro works.
As with Beneath a Steel Sky, it works fine when RetroArch is run from retroarch_debug.exe

[ner00]

Could some dev look at this issue though? The resolution may be trivial, not sure why nobody commented on it yet.

[ner00]

Worthy of mention, I've been directed to different build, found through https://github.com/libretro/scummvm/issues/179 but unfortunately it doesn't seem to make any difference.

[ner00]

Another game that seems to be affected, even if slightly:
The Legend of Kyrandia - Malcolm's Revenge (DOS) (affects intro only it seems).

[hizzlekizzle]

I asked some other people to test and they verified the same behavior with the list of games you had mentioned elsewhere:
Beneath a Steel Sky
Bud Tucker in Double Trouble
Drascula - The Vampire Strikes Back
Gobliins 2
Goblins 3
Leisure Suit Larry 7 - Love for Sail
Toonstruck
Touche
Woodruff and the Schnibble of Azimut
I'm not sure how we can debug this, though, when they only have issues on binaries that have been stripped.

[ner00]

I'm not sure how we can debug this, though, when they only have issues on binaries that have been stripped.

I'm not sure what you mean by that, every ScummVM game has been stripped of binaries / doesn't use them.

EDIT: One starting point would be to understand what does the debug executable include that the base executable doesn't - lots of things given the size, but nonetheless something outstanding enough to make a difference between working fine and not working fine or at all.

[hizzlekizzle]

By "stripped", I meant the retroarch executable has had the debug symbols stripped.

[ner00]

By "stripped", I meant the retroarch executable has had the debug symbols stripped.

Gotcha, dunno either how to proceed here.

In case you don't have retroarch_debug.exe and need it, grab it here (x64, v1.90 [6388872])

[Jamiras]

Older version I was able to test where this issue is present is v1.8.5

I was able to verify the problem exists in 1.8.2, which is the oldest version I have available.

I was also able to reproduce the issue using a locally built release build of 1.9.10 (54d2ac9). The stack track appears to be entirely in scummvm_libretro.dll:

Which suggests stack corruption. This is the main thread, and should eventually trace back to runloop_iterate.

I was not able to reproduce using a locally built scummvm_libretro.dll, or a locally built debug build of 1.9.10. I was able to reproduce using a debug build with /O2 (optimized, but should still have debug symbols defined), but it provided no additional useful information.

Testing was performed with the Gobliins 2 CD as mentioned in the linked issue above. After the intro starts playing, press Scroll Lock to engage Game Mode, then hit Escape to get to the main menu, and Escape again to start loading the game.

[hizzlekizzle]

Ohh, could it be one of those elusive compiler optimization bugs? So, RA-dbg-O2 crashes with any scummvm? When you said you couldn't reproduce using a locally built scummvm, did you try different optimization levels?

[Jamiras]

When you said you couldn't reproduce using a locally built scummvm, did you try different optimization levels?

I just did a make in the libretro/build directory using an msys2 prompt. I did try changing this line: https://github.com/libretro/scummvm/blob/master/backends/platform/libretro/build/Makefile#L2, but no other changes.

[ghost]

I just compiled the latest retroarch(normal version not debug) and used the core downloader started goblins 2 to test I getting no segfault on linux anyway. I load the game enable game focus and press escape and the game starts could this be a windows issue or is there something I should be looking out for?

[ner00]

I just compiled the latest retroarch(normal version not debug) and used the core downloader started goblins 2 to test I getting no segfault on linux anyway. I load the game enable game focus and press escape and the game starts could this be a windows issue or is there something I should be looking out for?

You are the first person to vouch for the integrity under Linux, so it's not far fetched that it is a Windows only issue; nonetheless, it's an issue caused by RetroArch - or at the very least its Windows compilation optimization given the previous experiences from other users.

[ghost]

I looked at the makefile I could be wrong here but if your using 64 bit windows can you try building with BUILD_64BIT=1 in the build process (for scumm) if your not doing that already im assuming your using gcc

[ner00]

@hizzlekizzle or @Jamiras could maybe test this, I don't have a setup ready to build myself.

[Jamiras]

I looked at the makefile I could be wrong here but if your using 64 bit windows can you try building with BUILD_64BIT=1 in the build process (for scumm) if your not doing that already im assuming your using gcc

I believe that is implicitly happening via this logic: https://github.com/libretro/scummvm/blob/5e485b40f89d6d8e38d8f5da0e807205390f3038/backends/platform/libretro/build/Makefile#L60-L61

But I tried explicitly specifying it and there didn't seem to be any difference. My locally built DLL continued to not display the problem.

When you said you couldn't reproduce using a locally built scummvm, did you try different optimization levels?

I have verified that the default make build for scummvm_libretro.dll is using "-O3". I changed this to "-O2" and I still could not reproduce with my locally built DLL.

For comparison, the buildbot DLL is 52MB. My normally built local DLL is 56MB. My -O2 build is 46MB. My DEBUG=1 build is 54MB. How is the buildbot DLL built?

You are the first person to vouch for the integrity under Linux, so it's not far fetched that it is a Windows only issue

I also tried a release build on Ubuntu with the buildbot .so, and the problem did not occur there. I did not try building the .so myself.

[triggerthehorizon]

I have the same bug on android