lr-genesis-plus-gx crashes on Master System Light Gun games

[msheehan79]

I just recently got a new Mayflash Dolphinbar to try out some light gun games and I've found that the lr-genesis-plus-gx core has a pretty consistent crash on most gun games right after I set the controller type to the MS Light Phaser controller. It crashes on my RPI3 (specs below) but not on my Windows x64 computer so I'm not sure if its something odd with my setup or not.

System:
RPI3
RetroArch 1.6.9 (Updated from Binary - also tried 1.7.0 update from source)
lr-genesis-plus-gx build 7104058 (latest binary - also tried update from source as well)

RetroArch Config:
Reset the retroarch.cfg file to the RetroPie default one, no core/game override files

To reproduce the issue, just load a light gun Master System game (example Rambo III, Operation Wolf, or Laser Ghost), open RGUI and change the controller type to "MS Light Phaser". Almost every time upon exiting RGUI the core will crash with an illegal instruction.

\shm\runcommand.log contents:
/opt/retropie/supplementary/runcommand/runcommand.sh: line 1007: 8079 Illegal instruction /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-genesis-plus-gx/genesis_plus_gx_libretro.so --config /opt/retropie/configs/mastersystem/retroarch.cfg "/home/pi/RetroPie/roms/mastersystem/Rambo III (USA, Europe).7z" --appendconfig /dev/shm/retroarch.cfg

I will add this happens even without the dolphinbar connected, so that doesn't appear to be a factor in this, other than that is what got me started with testing light gun games to begin with.

At this point I am curious if anyone with a similar version setup could try the above and confirm if they get the same results or not, to try and determine if this is an issue with the core/RA or if it's something odd going on with my setup.

[msheehan79]

An update to my original post - I have installed a clean RetroPie 4.3 image to make sure I am testing on a "vanilla" environment. It is looking to me like something has broken somewhere between RetroArch 1.6.7 and 1.6.9 with regards to this core.

Test - launch Rambo III (USA, Europe) SMS rom, select "MS Light Phaser" as the player 1 controller.

1st Test
Fresh RetroPie 4.3 image installed
RetroArch v1.6.7
lr-genesis-plus-gx build 997360b
Results - Game loads fine, the trigger on the wiimote does fire the gun but no movement is tracked so the crosshairs stay in the center of the screen.

2nd Test
RetroArch v1.6.7
lr-genesis-plus-gx build 7104058 (updated core from RetroPie binary)
Results - Game loads fine, the trigger on the wiimote does fire the gun but no movement is tracked so the crosshairs stay in the center of the screen.

3rd Test
RetroArch v1.6.9
lr-genesis-plus-gx build 7104058 (updated core from RetroPie binary)
Results - Game crashes with the "Illegal Instruction" error as originally reported.

4th Test
RetroArch v1.6.9
lr-genesis-plus-gx build 7176e8a (updated core from source)
Results - Game crashes with the "Illegal Instruction" error as originally reported.

So at this point I have to assume it's either a RetroArch or core bug since it happens consistently as soon as I updated to RA 1.6.9.

I also loaded RA 1.6.9 on my Windows 10 x64 environment, and the crash does NOT occur there with the latest core (7176e8a). So it's definitely platform-related in some fashion.

I guess at this point is there anything further I should check before logging an issue on the github repo?

[jonnykesh]

@msheehan79 This is good anecdotal stuff but you will need some logs in order to find the issue. Launch a game, hit a button, bring up the runcommand menu and launch with verbose logging.
When it crashes go to /dev/shm/runcommand.log to obtain the full log. This might be a lot so put it on a site like pastebin and post a link.

[msheehan79]

@jonnykesh thanks for the follow up.

Here is a log with verbose logging enabled.

EDIT - the first log below has a KVM keyboard/mouse switch plugged in, in addition to the dolphinbar and a gamepad, which is why so many keyboard/mouse devices are listed. I disconnected the KVM and ran a new log so it's only 1 gamepad and the dolphinbar.

Also during this testing, I found that with no keyboard/mouse devices plugged in the core doesn't crash. Once either the KVM or the dolphinbar is added it crashes so the issue seems to be with how it is handling these types of input devices.

Log 1 (with KVM) - https://pastebin.com/QTTyJ5gt

Log 2 (just dolphinbar + gamepad) - https://pastebin.com/ZHvxYmE5

[jonnykesh]

@msheehan79 I just tried it on my Laptop using settings of MS Light Phaser and in Options = Show crosshair. It worked perfectly using the mouse and mouse buttons.
I'll be honest I'm not familiar with the hardware you are using so I can't be of much further help but it's clearly something in the hardware setup.
Other people here use the Dolphin bar so hopefully they can help further.

[msheehan79]

@jonnykesh

Yes it's definitely odd. It works fine on my desktop PC with Windows too but not on the Raspberry Pi 3, so in terms of hardware it seems the Pi is the differentiating factor. Thanks for checking your end to confirm it works on a laptop as well.

[jonnykesh]

@msheehan79 No problem. I would recommend starting a new thread with Dolphin Bar in the name. It will grab the attention of those that know.

[msheehan79]

Thanks - but I don't think it's a Dolphinbar specific issue. I can get it to crash with just a plain old keyboard/mouse switch too.

Doing a bit of debugging work I have found if I comment out this bit of code on line 2489 of libretro.c it no longer crashes. You lose the crosshairs obviously but otherwise it works fine, so it seems that something in the crosshair generating code is related to the crash. At least now I've got an idea of where the crash is originating from, I'll see if I can debug further and once I've got some better idea of the root cause I can post the issue to the core's github repo for further discussion.

Lines 2487 - 2490 on libretro.c

  if (input.system[0] == SYSTEM_LIGHTPHASER)
  {
     //draw_cursor(input.analog[0][0], input.analog[0][1], 0x001f);
  }