3DS: RIVEN: "Could not find any engine capable of running the selected game"

[BallM4788]

ScummVM version: daily build 671298f2 (2.8.0 release binary not on the SCUMMVM website downloads page) ​https://buildbot.scummvm.org/dailybuilds/master/3ds-master-671298f2.zip

Bug details: Attempting to run Riven brings up a black screen for several seconds followed by the "Could not find any engine capable of running the selected game" message, followed by the kickback to the launcher menu. I don't know if any other Mohawk games or other engines are affected; the only other game I tried was Sam & Max, and that worked fine.

Language of game: English

Version of game: GOG.com release

Your OS, including version and device if appropriate: New Nintendo 3DS, Sys. 11.17.0-50U, Luma 13.0.2

If this bug only occurred recently, please note the last version without the bug, and the first version including the bug: Bug was introduced with this pull: ​https://github.com/scummvm/scummvm/pull/5552 , at this commit: ​https://github.com/scummvm/scummvm/commit/6522c6e11d2cfb60bef8972bfa4ee5716b012873 .

[BallM4788]

Working my way forward from the 2.7.0 release to find the commit that introduced the bug; so far Riven still works as of this Oct 16 commit: ​https://github.com/scummvm/scummvm/commit/e918ce9bc689784d18349e5094a1ce79bc231336

EDIT: Narrowed it down to between Dec 25 and Jan 1.

EDIT 2: Bug was introduced with this pull: ​https://github.com/scummvm/scummvm/pull/5552 . Editing the OP to reflect this.

[BallM4788]

GDB output:

GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from scummvm.elf...
(gdb) target remote 192.168.1.240:4000
Remote debugging using 192.168.1.240:4000
svcWaitSynchronization ()
    at /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/svc.s:263
263     /Users/davem/projects/devkitpro/pacman-packages/libctru/src/libctru-2.3.1/libctru/source/svc.s: No such file or directory.
(gdb) c
Continuing.
User picked target 'riven' (engine ID 'mohawk', game ID 'riven')...
   Looking for a plugin supporting this target... Mohawk
WARNING: elfloader: Unknown relocation type 0.!
WARNING: elfloader: Failed loading plugin 'romfs:/plugins/mohawk.plg'!
WARNING: elfloader: Unknown relocation type 0.!
WARNING: elfloader: Failed loading plugin 'romfs:/plugins/mohawk.plg'!
WARNING: elfloader: Unknown relocation type 0.!
WARNING: elfloader: Failed loading plugin 'romfs:/plugins/mohawk.plg'!
3ds initsize w:320 h:200

[tag2015]

Thanks for looking into this, could you check if this commit is also the culprit of bug #14837? Any AGS game will do (it seems the engine is disabled/can't be loaded)

[BallM4788]

Replying to tag2015:

Thanks for looking into this, could you check if this commit is also the culprit of bug #14837? Any AGS game will do (it seems the engine is disabled/can't be loaded)

Just got finished checking it out. Yeah, it seems to be the same thing happening there, and the same commit causing it as well. Here's the thing, though:

• Full build with all engines - Riven and AGS (and maybe other engines) trigger the bug
• Build with just the Riven engine - Riven triggers the bug
• Build with just the AGS engine - AGS triggers the bug
• Build with just the Riven AND AGS engines - Riven and AGS both work perfectly

Now I don't know much at all about how plugins and linking work, but here's what I'm thinking:

There was a ​hack fix for ticket:11555 where "Setting the base address for the plugin elf files high in memory forces the linker to generate veneers to turn relative jumps to the main binary into absolute jumps." A side benefit of this was that "This also removes the need to handle the R_ARM_CALL and R_ARM_JUMP24 relocation types." Based on the GDB output in comment:5, I'm guessing that something about changing the Graphics::PixelFormat constructors into constexprs is interfering with the hack fix, causing plugin linking to fail for certain engines based on what engines are being included.

Like I said, I don't know jack about how plugins and linking and so on work. But if someone who knows more about it than me says I'm right, the options are probably to either revert the 6522c6e commit or figure out how to implement proper relocation.

Discarding the speculation and going off what we actually know for sure right now, I'd say the simplest option is to just revert the 6522c6e commit if doing so won't break anything else.

[BallM4788]

Marking ticket as resolved since ​this commit has fixed the bug. The cause of the bug was, in fact, an issue in plugin linking, specifically that NONE relocations had not been implemented. To quote ​lephilousophe:

Relocation of type 0 is a NONE relocation for which nothing is to be done but which indicates dependencies between sections (quite obscure to me).