Pi4 RetroArch xmb segmentation fault with any Overlay bezel on

RetroArch Linux devices
#1

Raspberry Pi400 with updated Bullseye and firmware:

Using generally available overlays with RetroArch git, launching content from another frontend, such as ozone, runs and closes without issue. Launching the same content with an overlay ‘on’ also runs fine from xmb, but on content quit, the xmb frontend fails with a ‘segmentation fault’. Simply turning the overlay ‘off’ allows content to run and quit from xmb without issue.

Same git code and compile options on latest Fedora off Intel Linux, xmb content with an overlay ‘on’ runs and quits from xmb without issue.

#2

any chance you could bisect it and help us find when/where it broke?

#3

I started to do bisect as suggested, but realized I never had overlays on fully before with Pi (first tried RetroArch on Pi using Lakka this past November) – I just tinkered with overlays then but left them off, and decided to implement them more recently when I got better acclimated with the project, builds, and Raspbian overall. And now with the recent performance gains on Pi, I thought I could allow for the overlay overhead for its nice eye candy.

So, finding ‘good’ using v1.10.3, v1.10.2, v1.10.1 (and without any of the typical optimizations on) was fruitless with the same behavior for me. Makes no difference using gl, glcore, or vulkan. As a hail mary, I tried rebuilding Stella and MAME 2003-Plus cores hoping there was some API shutdown issue between them, no joy.

To me, this isn’t worth the level of effort to hunt down. It is a technical curiosity why a different frontend can close content (with an overlay) cleanly, while xmb (on Pi) does not. I posted a github issue in reference to this post.

1 Like
#4

Breaking news: seems that layering the configuration file may be introducing an internal complication.

If I start with a clean retroarch.cfg and change from default ozone to xmb, then quit to re-launch retroarch into xmb, then content with overlays will run & quit without segmentation fault.

I have retroarch.cfg and multiple cfg files for append, i.e.,

retroarch --appendconfig="$RA/play.cfg|$RA/myarcade.cfg"

… whereas retroarch.cfg has menu_driver = “ozone” but is replaced with play.cfg menu_driver = “xmb”

If I have retroarch.cfg set with menu_driver = “xmb” to start with, no issues with content running with an overlay quitting back to retroarch.

1 Like
#5

Addendum

I simply commented the main retroarch.cfg line as: #menu_driver = "ozone" since it is the “default”, and the play.cfg can set it as “xmb” allowing for content with an overlay to quit without crashing.

Clearly, having it coded in the configuration file, only to have it replaced later in an appended configuration files, starts something up internally within retroarch that lead to this bad behavior.

Off-topic but related to this configuration file “append” feature: if menu_mouse_enable = "true" then setting it to “false” in an appended file has no effect.

1 Like
#6

that’s a very weird issue. thanks for exploring it.

#7

It gets worse… the quit_on_close_content feature in an appended configuration file is no longer respected – and I know that was indeed working until very recently.

So this might be worth a bisect, because I see a lot of changes were made to configuration.c:

#8

k, let me know what you find out there, yeah

#9

SMH, after running bisect iterations between v1.10.3 (assumed good) and current (assumed bad), --appendconfig does not work as I believed it should, i.e., these two files contain:

retroarch.cfg: quit_on_close_content = "0"

one-shot.cfg: quit_on_close_content = "1"

retroarch --appendconfig="/retroarch/one-shot.cfg" -L mame2003_plus_libretro.so "/retroarch/roms/MAME 2003-Plus/asteroid.zip"

Press hotkey to QUIT content, goes back to menu! I commented out:

retroarch.cfg: #quit_on_close_content = "0"

… and hotkey to QUIT content goes back to CLI as expected. That tells me two things:

  1. it was likely segmentation faulting before (I do have &> /dev/null in my menu.sh script) because of the menu_driver = "ozone" -> "xmb" override using --appendconfig does not work either.
  2. configure.c is not replacing setting(s) when it encounters another like later in the chain – which IMO defeats the purpose of having this option. I can, of course, workaround this with a lot more complexity in the various cfg files, sigh.
#10

that is indeed how appendconfig is supposed to work. That’s pretty much its only purpose, AFAIK.

#11

Perhaps related, I made one change and dropped the --enable-qt feature (I run retroarch from both lightdm and virtual console vt1) from the compile off the latest git code – because I noticed it makes a retroarch_qt.cfg file in the same path. It should not collide/coerce/corrupt any of this, but yet, now it’s back to behaving as expected.

Go figure. :nerd_face:

1 Like
#12

Damn, reported that false-positive too soon… my unit-test above outside my menu.sh script (which includes an rsync -a template.cfg retroarch.cfg to assure the original state is restored) was faulty, so it was running with a prior config_save_on_exit state – which is another override not respected, because I have it coded as “false” in an appended config.

I’m grasping at straws here, but I have a viable path ahead now by commenting out some critical default values (config_save_on_exit, menu_driver, menu_mouse_enable, quit_on_close_content, etc.), to allow for appendconfig to do its “first set” into the runtime.