Segfault from: #446 "Add support for 64 Disk Drive"

[hissingshark]

Hi, it's the first time this year I've rebuilt from master and I'm getting a segfault, which I've bisected back to commit e302bc2 "Add support for 64 Disk Drive".

Mario Kart shows the spinning logo at the start but segfaults just before the start screen.
Super Smash Bros segfaults during the intro animation.

I'm on armv8, Amlogic S905x (Mali 450 GPU). GLES2. And I was using the mupen64plus-video-n64 plugin.

Anything I can provide to assist debugging?

[bsmiles32]

Hi @hissingshark

thanks for reporting (and bissecting) your issue here. We will need some more information in order to assist in the debugging. See below:

• Which emulation mode do you use : interpreter, cached interpreter, or new_dynarec ?
• Can you provide a backtrace of said crash ? You will need to compile with debug symbols (eg DEBUG=1) for it to be usable. Then running mupen64plus under gdb using something along the lines of :

gdb --args mupen64plus --corelib <path_to_my_compiled_version_of_libmupen64plus> --datadir <path_to_corresponding_data_dir>  --emumode <{0,1,2}> my_rom.z64

then inside the gdb console type "r" (for run), and when the program crashes, you can type "bt" (backtrace) to get the backtrace at the moment of the crash.

[hissingshark]

Thought it might be something like that! Thanks for getting back to me.
Well, it's mixed results here.
The segfault doesn't reproduce if compiled as DEBUG, so I can't get a backtrace. I think this is what the kids call a "Heisenbug". When reading up on the term "optimisation" came up, so I thought I'd try compiling with the -O2 CFLAG instead of the -O3 I had been using and no segfault either.

[bsmiles32]

When building did you started from a "fresh" compilation or not (eg. make clean && make all) ?
I ask because, in order to share C struct definitions between C and assembler, we use some "magic" which generate some header files with proper members offsets. These headers MUST be regenereted when compiler options get changed or when some structures get updated. Otherwise assembler will use outdated offsets and cause hard to debug crashes.

[hissingshark]

That's clean.
I've just reaffirmed for you with an unadulterated git clone -> build -> run -> segfault.

[fzurita]

Instead of building debug, simply add -g to the GCC flags. It will make the output binary much bigger because it will contain debug symbols, but it will not mess with the optimizations settings.

It does mean that you may lose some of the backtrace information due to the optimizations, but it's better than nothing.

[hissingshark]

I've tried adding -g to my initial export CFLAGS= but the file size is unchanged.
Unfortunatey gdb reports:

Reading symbols from mupen64plus...(no debugging symbols found)...done.

So at this point running under gdb yields:

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault.
0xf61c1060 in ?? () from ./libmupen64plus.so.2

And the backtrace:

#-1 0xf47c9840 in ?? () from ./libmupen64plus.so.2
Backtrace stopped: Cannot access memory at address 0x4efffff8

[fzurita]

Try these things:

• Interpreter instead of dynarec
• CXD4 HLE instead of RSP-HLE.
• Dummy audio plugin
• A different video plugin like GLideN64

[mrfixit2001]

I can confirm this is still an issue and that the correct commit was bisected. I am compiling on an ARM platform with rk3399 and encountered this segfault. I created a patch that reverses just this commit, compiled against the master branch, and no more segfault.

[hissingshark]

@fzurita Apologies. Didn't realise this had seen any further attention. Email updates going to spam... I shall try your suggestions.

@mrfixit2001 Would you be so kind as to try the suggestions above as well?

[hissingshark]

@fzurita

Interpreter instead of dynarec

--emumode 2 segfaults, but 0 and 1 were ok.

---

CXD4 HLE instead of RSP-HLE

--rsp mupen64plus-rsp-cxd4.so didn't seem to do anything after outputting the usual startup messages. No segfault, but just a blackscreen and no sound. I had trouble compiling it and had to use NEON=0 in the end, which may have something to do with it.

Dummy audio plugin

--audio dummy segfaults.

A different video plugin like GLideN64

--gfx mupen64plus-video-glide64mk2.so or mupen64plus-video-rice.so segfaults.

---

Can I assist any further?

[fzurita]

This goes beyond my area of expertise, but it sounds like there may be a bug in the dynarec causing your issue. @Gillou68310 may have more ideas.

[hissingshark]

@bsmiles32 @fzurita @richard42

This issue has stalled Mupen64Plus on the Vero4k for a year now.
On Retropie I was building from older commits for Vero4k. Now that's broken as other Mupen modules have continued to move forward and they can't build against each other.

I understand this has proven to be a complicated issue and I'm just trying to find a robust workaround:

1. A simple git revert e302bc2 would be good, but doesn't work anymore, no doubt because of other changes / multiple parents.
2. A manually constructed patch will only be good until further commits break that as well.
3. Would you accept a PR for a cmake option to disable 64 Disk Drive support? Would be a lot of #ifdefs essentially, but it would stand up better to future commits.

[hissingshark]

Further intel that may help narrow the source of the suspected dynarec issue here.

I have found an additional factor. Presently I build for S905x (armv8-a Cortex-A53) with the following CFLAGS:
-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard

But if I build as for the armv7 RPi2 then there is no runtime error:
-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard