runcommand segfaults with PPSSPP and sdl2 > 2.0.8
hissingshark last edited by hissingshark
This is on the OSMC Vero4K (tested on both Stretch and Buster).
RetroPie v4.6.8 (most recently tested)
All built from source.
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"
ui_atlas.zimfile 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
It's not the
runcommandthat crashes, it's the emulator, the SEGFAULT error is raised by the emulator (line 1270 is where the emulator is started via the
runcommandfunction 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 ?
@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.shthat 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?
Try modifying the
pspsystem and add the
-v -dflags to get more information in the log file (
ppsspp = "/opt/retropie/emulators/ppsspp/PPSSPPSDL -v -d --fullscreen %ROM%" default = "ppsspp"
@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
I've tried renaming PPSSPPSDL and putting it in an adjacent wrapper of:
#!/bin/bash /opt/retropie/emulators/ppsspp/PPSSPPSDL.hidden "$@"
Hm, can you try adding a
cd $HOMEcommand in the wrapper ? Maybe
ppsspp's starting folder has an impact on finding the assets.
@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.
You can try using
opencalls), at least this might give you an indication on the files not found error.
@mitu There is no reference to
However the prior failure in the log is for
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/ppssppand that worked launching from
Why the different path behaviour with newer SDL2? The PPSSPP sources suggest low-level file access, rather than anything SDL2 related.
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.