Mupen64 crashes when dynamic recompiler is used

[GaMMa]

I'm using the Linux version of the program (0.4) and when I try to start a game I get this message...

memory initialized
[glN64]: (II) Initializing SDL video subsystem...
[glN64]: (II) Getting video info...
[glN64]: (II) Setting video mode 640x480...
demarrage r4300
dynamic recompiler
Signal number 11 caught:
errno = 0 (Success)

Anyone have any ideas how to fix it or why it isn't working? I'm using the default plugins..

UPDATE: It works with Rice's video plugin, but I want to play Zelda which distorts the graphics on that plugin.

UPDATE2: Alsa plugin and all other audio plugins crash also. The default one plays, but I can't chane the buffer size without a crash..

 

[aminalshmu]

use jttl's SDL audio plugin, it works great for Zelda OOT. also the glN64 plugin works perfectly for me with that game...

 

[GaMMa]

Hacked the source to get jttl-sdl to compile, but it does

(II) JttL's sound plugin version 1.2
(II) Initializing SDL audio subsystem...
Signal number 17 caught:
errno = 0 (Success)

 

[Hacktarux]

Do you mean it only crashes with dynarec ? or does it crash too with interpreter ? If it crashes with all the cores, are you using gentoo's portage ? It looks like their scripts are breaking something in mupen64... You can also try to download precompiled binaries.

 

[GaMMa]

Unfortunately the precompiled binaries are GTK1. I think the Gentoo version patches the source with the GTK patch and what not.. I should have made 2 seperate threads for this. Dynamic Recompiler crashes all the time unless I use Rice's plugin. glN64 doesn't work with it (both core and plugin compiled by me).

2nd problem: I can't get anything other than the default sound plugin running. jttl's sdl and alsasnd both crash on startup with an error code 17.

 

[Hacktarux]

Ok, well, i'm almost sure it's gentoo patch issue, i can't do anything...

 

[GaMMa]

Got things working.. I think a combination of scrict CFLAGS and the Gentoo patches broke everything . Works great now though

EDIT: I'm still getting random crashes every now and then though. It seems when I go to a new area in Zelda it decides to crash. I saw an old thread that suggested uncommenting a line as a solution, but in .4 that line is uncommented...

 

[ciruZ]

GaMMa: I guess it's better when you test the precompiled binary first and test if it works there. Gentoo often breaks a lot with their ugly patches (and that's the reason why this distro IMO sucks a lot).

 

[Joky]

I've build a 0.5 binary inside my x86 chroot manualy to make sure
it's not Gentoo's Portage or some of the patches.

I still get the segfault when it wants to initialize the "Dynamic Recompiler".

I'm running and the x86 32bit binary on my AMD64 system.
(i only have x86_64 machines no real x86, and all the people
i know which could fix the type issues to build a real 64bit
binary are busy )

I also looked at the patch for 0.5 and it only changes paths
from "share/mupen64/" to "lib/mupen64/" and an "rm" to "rm -f"
Other than that, the build file changes the CFLAGS to the global
configured ones.

But as i said, to be 100% sure i've built the binaries manualy and still
got that issue. Ofcourse it could still be a distro issue like GCC4.1
or glibc2.4 etc. I also tried lowering the optimisation to -march=i686 -O2
only. I'll try with a prebuilt binary later.

 

[Joky]

Ok, i've now downloaded the "official" binaries from the mupen64
homepage and it exactly segfaults the same way with "Dynamic Recompiler"

So it's not a build, but either a bug or a runtime component issue.

It also happens when i try with dummy audio and software gfx so
it doesn't seem plugin related.

 

[Joky]

Ok just got the following info from someone:

Dynamic recompiler works by turning NX/XD off on boot (append noexec=off to
kernel parameter line). So my guess is that mupen64 is probably not correctly
setting memory permissions on the memory mappings where it places the
recompiled code and then executes it there. I'll try and have a look at the
code to see if it is possible to apply a small patch to fix this (if this is
indeed the issue).

 

[Nonno Cicala]

Thank you for the noexec hint!
I am in the same situation. My workaround until now was to use an older kernel, there wasn't any problem with gentoo-sources-2.6.16-r13. I'm happy that I'm not stuck with it anymore.