Segmentation Faults in runcommand.sh when running N64 Games

mitu

@mjs2011 said in Segmentation Faults in runcommand.sh when running N64 Games:

Any advice on how to further troubleshoot this issue?

Do you have an overclocked system ? Then remove the overclock and try again.
Use an official power supply - funny things happen when thre proper power is not provided to SBCs.

If you run dmesg | tail after the crash (from a command prompt), are there any error messages. Did you also update the system's packages when updating RetroPie ?

My next step is to attempt another fresh install of retropie and to load only one game to attempt it that way.

Not sure if that would help, unless you've added some configuration to cause this issue which might be solved with the default configs.

mjs2011

@mitu said in Segmentation Faults in runcommand.sh when running N64 Games:

@mjs2011 said in Segmentation Faults in runcommand.sh when running N64 Games:

Any advice on how to further troubleshoot this issue?

Do you have an overclocked system ? Then remove the overclock and try again.

Use an official power supply - funny things happen when thre proper power is not provided to SBCs.

If you run dmesg | tail after the crash (from a command prompt), are there any error messages. Did you also update the system's packages when updating RetroPie ?

My next step is to attempt another fresh install of retropie and to load only one game to attempt it that way.

Not sure if that would help, unless you've added some configuration to cause this issue which might be solved with the default configs.

Thanks for the reply.

I'm not overclocked. I'll try the official power supply tonight. The one I'm running is a higher amp rated supply with a power switch that has treated me well, but I'll give the official supply a go to rule it out.

I'll also run dmesg | tail and see if it shows anything after a crash.

I can't remember if I updated system packages as well or not when updating the emulators. Is there any way to tell?

mjs2011

Here's an update.

Official Raspberry Pi power supply made no change.
Confirmed no overclock in the /boot/config.txt file, and also ran

watch -n 1 vcgencmd measure_clock arm

to confirm that the clock speed wasn't exceeding the default for the pi4.

Lastly, here are some more output log files.

from /dev/shm/runcommand.log

Parameters:
Executing: SDL_VIDEO_KMSDRM_CRTCID=87 SDL_VIDEO_KMSDRM_MODEID=41 /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so --config /opt/retropie/configs/n64/retroarch.cfg "/home/pi/RetroPie/roms/n64/Legend of Zelda, The - Ocarina of Time (U) (V1.2) [!].v64" --appendconfig /dev/shm/retroarch.cfg

/opt/retropie/supplementary/runcommand/runcommand.sh: line 1319: 1034 Segmentation fault SDL_VIDEO_KMSDRM_CRTCID=87 SDL_VIDEO_KMSDRM_MODEID=41 /opt/retropie/emulators/retroarch/bin/retroarch -L /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so --config /opt/retropie/configs/n64/retroarch.cfg "/home/pi/RetroPie/roms/n64/Legend of Zelda, The - Ocarina of Time (U) (V1.2) [!].v64" --appendconfig /dev/shm/retroarch.cfg

some different values for SDL_VIDEO_KMSDRM_CRTCID and ""MODEID than the prior runcommand.log file, but the same segmentation fault at line 1319.

And now here is the results of dmesg | tail (I can provde the full dmesg if needed, but its quite long. The tail was captured immediately after a game crash)

[ 4419.025503] usb 1-1.3: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[ 4419.025524] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4419.025542] usb 1-1.3: Product: Xbox 360 Controller for windows
[ 4419.025560] usb 1-1.3: Manufacturer: Microsoft Inc.
[ 4419.025577] usb 1-1.3: SerialNumber: 254F1E4
[ 4419.084942] xpad: loading out-of-tree module taints kernel.
[ 4419.087479] input: Microsoft X-Box 360 pad as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3:1.0/input/input13
[ 4419.089143] usbcore: registered new interface driver xpad
[ 4615.854316] process 'emulators/retroarch/bin/retroarch' started with executable stack
[ 4641.351502] v3d fec00000.v3d: MMU error from client L2T (0) at 0x82c1000, pte invalid

Hopefully something here sheds some more light on the issue.

mitu

@mjs2011 said in Segmentation Faults in runcommand.sh when running N64 Games:

some different values for SDL_VIDEO_KMSDRM_CRTCID and ""MODEID than the prior runcommand.log file, but the same segmentation fault at line 1319.

Yes, it's the same line since is the emulator that's crashing, the SDL_ env variables are just for setting up the resolution.

And now here is the results of dmesg | tail (I can provde the full dmesg if needed, but its quite long. The tail was captured immediately after a game crash)

Yeah, nothing stands out. The last line is an error, but it's benign and wouldn't cause the crash.

Can you get a verbose log and post it on pastebin.com ?

mjs2011

@mitu

Here's the pastebin for the runcommand.log verbose log of a crash just now.
https://pastebin.com/aNrNpfgS

mitu

Hm, nothing new in the log from the emulator.
I'll check to see if there's any regression with the core, but nobody reported that recently. Did you try the standalone emulator, does it exhibit the same issue ?

skankieflank

@mitu
I have the exact same error after recently updating lr-bluesmsx.

The error only happens on launching any msx2 game.

I also tested this on another pi4 setup I have and it does the same thing after updating the core.

I tried reinstalling and remove and install but error still happens so replaced the core with a backup I had made and works as expected.

mitu

@skankieflank said in Segmentation Faults in runcommand.sh when running N64 Games:

I have the exact same error after recently updating lr-bluesmsx.

Please open a separate topic and provide the info asked in https://retropie.org.uk/forum/topic/3/read-this-first.

skankieflank

@mitu
Thanks will do.

skankieflank

This post is deleted!

mjs2011

@mitu said in Segmentation Faults in runcommand.sh when running N64 Games:

Hm, nothing new in the log from the emulator.
I'll check to see if there's any regression with the core, but nobody reported that recently. Did you try the standalone emulator, does it exhibit the same issue ?

Forgive my ignorance, but what is the standalone emulator?

When launching a game, I get the option to press a button to configure, and there are 6 options to choose from:

lr-mupen64plus-next
lr-mupen64plus
mupen64plus-gles2n64
mupen64plus-gles2rice
mupen64plus-GLideN64-highres
mupen64plus-GLideN64

Most of my playing has been with lr-mupen64plus-next, and a bit with lr-mupen64. I get crashes in both, but lr-mupen64plus-next seems to run smoother overall than lr-mupen64plus.

Admittedly, I haven't played much with the not libretro emulators that I can choose from, mainly because I already have a save file with the lr-mupen64 emulators that works for both. In that regard, is there a way to take a save file for the lr-mupen64plus-next emulator and convert it to work with one of the other 4 non lr emulators? that would allow me to test those out in more detail.

sleve_mcdichael

@mjs2011 lr- are the libretro (RetroArch) emulators, the ones without are the stand-alone versions.

mjs2011

I was able to convert my .srm save file from lr-mupen64plus-next to an .sra file with this online tool.

https://drehren.github.io/ramp64-convert-web/

I then copied the .sra file into /opt/retropie/configs/n64/mupen64plus/save/

Then I launched ocarina of time with mupen64plus-GLideN64 and played it nonstop for about 2 hours without any crashes or major issues. GLideN64 may have had a few more video glitches than lr-mupen64plus-next was having, but not a single crash for that entire period of time, and that was picking up the game where I left off playing with lr-mupen64plus-next.

So it seems that I don't have these crashes with standalone emulators, but do with libretro emulators.