Open hissingshark opened 6 years ago
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:
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.
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.
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.
That's clean. I've just reaffirmed for you with an unadulterated git clone -> build -> run -> segfault.
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.
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
Try these things:
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.
@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?
@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?
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.
@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:
git revert e302bc2
would be good, but doesn't work anymore, no doubt because of other changes / multiple parents.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
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?