runcommand segfaults with PPSSPP and sdl2 > 2.0.8

[hissingshark]

This is on the OSMC Vero4K (tested on both Stretch and Buster).
RetroPie v4.6.8 (most recently tested)
All built from source.

Issue:
PPSSPP worked fine on SDL2-2.0.8.
Once upgraded to 2.0.10 the following results when launching from EmulationStation.

19:24:548 Common/MsgHandler.cpp:45 E[SYSTEM]: Warning: Failed to load ui_atlas.zim.
Place it in the directory "assets" under your PPSSPP directory.
 
/opt/retropie/supplementary/runcommand/runcommand.sh: line 1270: 19650 Segmentation fault /opt/retropie/emulators/ppsspp/PPSSPPSDL --fullscreen "/home/osmc/RetroPie/roms/psp/Tekken 6.iso"

Findings:

• The ui_atlas.zim file is actually there, as it ever was.
• A complete re-install/rebuild of PPSSPP doesn't help.
• On a fresh RetroPie install the first run of PPSSPP actually worked, but segfaults on all subsequent runs.
• Down/upgrading SDL2 between 2.0.8 and 2.0.10 consistently toggles the fault (I recall 2.0.9 was also an issue but I don't have an archive to hand).
• Running PPSSPP directly from the commandline outside of runcommand.sh works fine.

Many thanks,

[mitu]

It's not the runcommand that crashes, it's the emulator, the SEGFAULT error is raised by the emulator (line 1270 is where the emulator is started via the runcommand function in the script).
Is the same command used by runcommand - /opt/retropie/emulators/ppsspp/PPSSPPSDL --fullscreen "/home/osmc/RetroPie/roms/psp/Tekken 6.iso" - working, if started from a command line ?

[hissingshark]

@mitu Thanks for getting back to me.

Yeah, that's what I meant by running from the command line. I even cut and pasted the same command from the log, just to be consistent, and it ran fine. That's why I thought it was runcommand.sh that was segfaulting. I understand what you mean about the line number though.

Is there anything else you'd like me to test at this end?

[mitu]

Try modifying the emulators.cfg for the psp system and add the -v -d flags to get more information in the log file (/dev/shm/runcommand.log):

ppsspp = "/opt/retropie/emulators/ppsspp/PPSSPPSDL -v -d --fullscreen %ROM%"
default = "ppsspp"

[hissingshark]

@mitu No additional lines in the log.

I notice there is also:

loading control pad mappings from gamecontrollerdb.txt: gamecontrollerdb.txt missing

Whereas running directly from the commandline gives:

loading control pad mappings from gamecontrollerdb.txt: SUCCESS!

This too is stored in the assets folder...

I've tried renaming PPSSPPSDL and putting it in an adjacent wrapper of:

#!/bin/bash
/opt/retropie/emulators/ppsspp/PPSSPPSDL.hidden "$@"

No change.

[mitu]

Hm, can you try adding a cd $HOME command in the wrapper ? Maybe ppsspp's starting folder has an impact on finding the assets.

[hissingshark]

@mitu No joy I'm afraid.
I'm looking through the PPSSPP source now, to see how the file loading is performed. It's assume if the fault is at their end that they'd have to be using SDL2 to do it, otherwise I don't see why a different version of it breaks it.

[mitu]

You can try using strace (filtering the open calls), at least this might give you an indication on the files not found error.

[hissingshark]

@mitu There is no reference to ui_atlas.zim at all.
However the prior failure in the log is for gamecontrollerdb.txt.
The strace from a runcomand launch shows:

openat(AT_FDCWD, "/opt/retropie/emulators/ppsspp/PPSSPPSDL.hidden\377\341V\312\253\tW\312\253\210\352\273\377\260f\311\253\260V\311\253\210\352\273\377/tmp/assets/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/retropie/emulators/ppsspp/PPSSPPSDL.hidden\377\341V\312\253\tW\312\253\210\352\273\377\260f\311\253\260V\311\253\210\352\273\377/tmp/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/ppsspp/assets/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "assets/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/osmc/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

So that 2nd from last attempt should be local to the emulator binary.
Launch directly from the command line:

openat(AT_FDCWD, "/opt/retropie/emulators/ppsspp/assets/gamecontrollerdb.txt", O_RDONLY|O_LARGEFILE) = 16

Success using the full path to the same location...
From the hint above I tried sudo ln -s /opt/retropie/emulators/ppsspp/ /usr/share/ppsspp and that worked launching from runcommand.
Why the different path behaviour with newer SDL2? The PPSSPP sources suggest low-level file access, rather than anything SDL2 related.

[mitu]

In 2.0.10, it looks like a hint was added (SDL_HINT_GAMECONTROLLERCONFIG_FILE) to point to a user chosen 'gamesdbcontroller.txt' file. It looks like PPSSPP doesn't use this mechanism to load the file, but it might affect how SDL2 works when the game controller API is initialized by the emulator.

I'll see if a recent source build for PPSSPP triggers this on a RPi, it could also be something that's changed in the emulator since the last binary build in RetroPie.