Mupen64plus: Zelda Majoras Mask - freeze

RetroArch Windows devices
#1

Hello!

I am on windows playing Zelda Majoras Mask using the mupen64plus core. At random points in the game it would simply freaze saying “This program does not respond anymore - Wait for answer - Quit”. Is there anything I can do about this? I have already tried different levels of GFX accuracy, different resolutions and different GFX plugins. This happened with version 1.2 as well as with 1.3 Here is a log using

retroarch.exe -v --menu 2>log.txt

http://pastebin.com/RUG0NrRM and one using

retroarch_debug.exe -v --menu 2>log.txt

http://pastebin.com/rBVqWb1L

But they don’t seem to be very useful… How do I obtain a debug logif not like this?

I also refrained from using save slots since one time I could not save in game after loading one of those. :frowning:

#2

If you get a random crash, the best way to get something informative is to run the program through gdb. You can download it from here: http://www.equation.com/servlet/equation.cmd?fa=gdb Drop it into the same folder with your retroarch.exe and run it by typing this into a command line: gdb.exe retroarch.exe and then, at the gdb prompt: run --verbose --menu This will start up retroarch and you can go about your normal usage until it freezes/crashes. Go back to your command line and type in: bt This will give you a backtrace of what happened.

#3

http://pastebin.com/Lz8NuJJN no luck, maybe I should run with retroarch_debug? Will try.

#4

I tried again with retroarch_debug. When it freezes, how can I interact with the process? I see a couple of Thread exited but the game is still running. When I close it and try to “backtrace” at the gdb command promt it tells me “no stack”…

#5

yeah, it’ll just freeze when it crashes. Leave it up frozen like that, switch over to your gdb prompt and then backtrace.

#6

Hey, I just got back to trying it again. I updated to 1.3.6 but still have the same issues. Continuing on your last answer: When the game freezes, the gdb promt is still busy executing the game, I cannot type any commands there. I tried opening a second gdb session and “attach” it to the process using its PID but it said “Can’t attach to process…”

#7

You can try the GLupeN64 core, it should play Majora’s Mask quite well

#8

Thanks for the tip but I think it would be nice if this could actually help to solve the issues. It feels like I’m just missing a small peace to get the backtrace…

#9

That’s odd that it’s still trying to run the process. I would actually echo loganmc10’s suggestion and just switch to GlupeN64 core.

#10

Majoras Mask is also freezing with normal Mupen64Plus and HLE RDP. I had the issue today with the orginal emulator, Mupen’s HLE RDP and GlideN64. So the freeze will most likely also occur in GLupeN64, because the issue is related to Mupen itself.

#11

Thank you for following up on this. I will try with GLupeN64 in the next days… I would really love to debug this - is there a way to tap into the running process using gdb even if the window is occupied still executing the (frozen) retroarch_debug? Thanks!

#12

i dunno if its related, but you seem to have timing/refresh rate issue. try a US release of the game-i cannot do test since i dont have a strong gl-capable card needed for n64 gpu emulation.

#13

I tried m64py with the same issue. Majoras Mask is freezing after a certain time.

Has anyone experience with GLupen64?

#14

i played the US version of this title, using Mupen64 on my crappy intel hd graphics, i do not have issue related to this thread like freezing or crashing. why you guys wanna play the EU version anyways…

#15

Because of the pretty good translation, which also children can understand :slight_smile:

#16

EU has better translation that US version?

#17

The US version has no translations at all, except of english. EU version contains english, german, french, spanish etc.

#18

Had the freeze also with GLupeN64. So it seems to be a timing issue in the core of Mupen64Plus. :frowning:

#19

Hi :slight_smile: i post to say i get the same issue. Retroarch + mupen64plus gfx on “auto”. On both Windows 10 and 7 64bits. Random freeze, i have to ctrl + shift + del. Experienced from 30sec of cinematic to 1h30 of gameplay.

I’m also using EU version, alternative is not possible due to translation (for family), as mentionned above.

(update: also crashed on retroarch-nightly version, with the GLupeN64 core)

#20

It would be nice if someone could give us more detail on how to debug the application using gdb. I think it could help. Problem is that we cannot tap into the frozen retroarch process to get the call stack…