search

libretro / libretro-fceumm

FCEUmm libretro port.
GNU General Public License v2.0
128 stars 115 forks source link

Segfault on launch with commit 7e7565e (September 20) #614

Closed carlosefr closed 1 month ago

carlosefr commented 1 month ago

I've upgraded lr-fceumm on my Raspberry Pi 3B (Debian Buster) to commit 7e7565e and it segfaults on launch. Rolled back to commit 744f5d9 and it works again. I've compiled it from source in both cases.

There were a bunch of commits on September 20 and one of those is likely the culprit. I'm not sure if I can safely downgrade to any one of them or if they're all part of a set of changes. If there's any specific commit you wish me to try, I'm happy to help.

PS: I've also upgraded to 7e7565e on an x86-64 machine (Ubuntu 22.04) and it doesn't segfault there.

LibretroAdmin commented 1 month ago

Did a git reset --hard, try to see if it works again. It should be reverted back to the last commit before that PR.

carlosefr commented 1 month ago

Will try in a few hours. I noticed this at first with a binary update from retropie_setup.sh before trying from source. Will check that too, not sure how that handles a branch going back in time (the binary download might not downgrade, and the source update might not pick up older commits).

I'll post here. And if I run into issues, I'll open an issue there (although force pushes are problematic, they should be able to handle them gracefully).

carlosefr commented 1 month ago

Confirmed that a build from current master works.

Seems retropie_setup.sh is able to correctly downgrade to the reverted commit when installed from source, but not when installed from binary. I've opened an issue there: https://github.com/RetroPie/RetroPie-Setup/issues/3972

negativeExponent commented 1 month ago

the only need fix for this issue was just suppose to be to increase MAX_CORE_OPTIONS om libretro_core_options.h from the default 37, to 48, to compensate for the new options added plus options from vsuni/dipswitch-enabled roms, not a complete revert. any issues (if there are any) should have been fixable and would get the core more upto date not just with mapper support...

if anyone wants this core updated, ill be maintaining my own repo of it, or if anyone knows any other active forks i can contribute there instead.

the next set of PR should have fixed those: https://github.com/negativeExponent/libretro-fceumm/commits/libretro/