mupen64_nogui seg fault

[sm1]

I am trying to configure my mythtv frontend, and having a few issues when getting mythgame working. I'm using mupen64_nogui to launch my n64 roms, but every time it launches, it just seg faults. If I launch it through regular mupen64, everything works fine (but has the gui in my way of course). If i clear out my ~/.mupen64/mupen64.conf file and rerun mupen64_nogui, it lets me choose all of the options from what used to be in my mupen64.conf file, and will run fine, but of course I would have to rechoose them each time.



I'm using mupen64 .5 on a gentoo linux. I used the ebuild at gentoo's bugzilla to build it. I use rice's plugin for video, blight's sdl for input, and the default audio provided by mupen for audio.

mythtv@mythtv ~ $ mupen64_nogui
Segmentation fault

mythtv@mythtv ~ $ cat .mupen64/mupen64.conf
[Default]
Audio Plugin = /home/mythtv/.mupen64/plugins/mupen64_audio.so
Input Plugin = /home/mythtv/.mupen64/plugins/blight_input.so
RSP Plugin = /home/mythtv/.mupen64/plugins/mupen64_hle_rsp_azimer.so
RomDirsScanRecursive = true
NoAudioDelay = false
NoCompiledJump = false
AutoIncSaveSlot = false
NumRomDirs = 1
Core = 1
MainWindow Width = 797
MainWindow Height = 570
RomBrowser ColWidth[0] = 235
RomBrowser ColWidth[1] = 32
RomBrowser ColWidth[2] = 57
RomBrowser ColWidth[3] = 42
RomBrowser ColWidth[4] = 358
RomDirectory[0] = /mnt/exports/music/roms/n64/
Gfx Plugin = /home/mythtv/.mupen64/plugins/ricedaedalus.so

mythtv@mythtv ~ $ ls -l .mupen64/plugins/
total 20
-rw-r--r--  1 mythtv users   549 Sep 12 21:41 RiceDaedalus.cfg
-rw-r--r--  1 mythtv users 13098 Sep 12 16:32 RiceDaedalus5.1.0.ini
lrwxrwxrwx  1 mythtv users    46 Sep 12 16:32 blight_input.so -> /usr/games/lib/mupen64/plugins/blight_input.so
lrwxrwxrwx  1 mythtv users    44 Sep 12 16:32 dummyaudio.so -> /usr/games/lib/mupen64/plugins/dummyaudio.so
lrwxrwxrwx  1 mythtv users    45 Sep 12 16:32 glN64-0.4.1.so -> /usr/games/lib/mupen64/plugins/glN64-0.4.1.so
lrwxrwxrwx  1 mythtv users    53 Sep 12 16:32 mupen64_alsasnd-0.4.so -> /usr/games/lib/mupen64/plugins/mupen64_alsasnd-0.4.so
lrwxrwxrwx  1 mythtv users    47 Sep 12 16:32 mupen64_audio.so -> /usr/games/lib/mupen64/plugins/mupen64_audio.so
lrwxrwxrwx  1 mythtv users    56 Sep 12 16:32 mupen64_hle_rsp_azimer.so -> /usr/games/lib/mupen64/plugins/mupen64_hle_rsp_azimer.so
lrwxrwxrwx  1 mythtv users    47 Sep 12 16:32 mupen64_input.so -> /usr/games/lib/mupen64/plugins/mupen64_input.so
lrwxrwxrwx  1 mythtv users    50 Sep 12 16:32 mupen64_soft_gfx.so -> /usr/games/lib/mupen64/plugins/mupen64_soft_gfx.so
lrwxrwxrwx  1 mythtv users    46 Sep 12 16:32 ricedaedalus.so -> /usr/games/lib/mupen64/plugins/ricedaedalus.so
lrwxrwxrwx  1 mythtv users    51 Sep 12 16:32 tr64gl-0.8.7-pre1.so -> /usr/games/lib/mupen64/plugins/tr64gl-0.8.7-pre1.so
lrwxrwxrwx  1 mythtv users    48 Sep 12 16:32 uhleaudio-0.1a.so -> /usr/games/lib/mupen64/plugins/uhleaudio-0.1a.so
mythtv@mythtv ~ $

Could anyone provide some insight to something obvious that could cause this segfault?

[rico99]

You probably figured it out by now but...

I ran into a similar problem and wondered what I was doing wrong.
It turns out it's just a case of lazy programming using the style of
"why print an error message when you can just crash?". The code
is littered with cases like this:

f = fopen(filename, "wb");
fwrite(flashram, 1, 0x20000, f);

The correct thing to do following an 'fopen' is to check for an error
and print a message. J'accuse!! (I'll send a list of patches
to Hacturux and maybe in the future this won't be so confusing.)
By the way, I should say that overall I'm impressed with what mupen64
can do and it's very cool. I just think it would help immensely with
usability to clean up things like error messages, etc. -- so people
who don't know how to run strace, etc. can figure out what's going.

Okay, so what about strace?

The fast way to work around a lack of error messages is to just run
strace like so:

% strace mupen64_nogui |& grep open

(or if you're running sh/bash: # strace mupen64_nogui 2>&1 | grep open)

If you're problem is the same as what I described above, then the
last open before the crash probably fails because a directory doesn't
exist, or you don't have write permission, etc.

Good luck!

-Rico99