mupen64plus-core
mupen64plus-core copied to clipboard
mupen64plus
Paper Mario crash when loading save states
Paper Mario sometimes crashes when loading save states. I suspect that it's because save states don't contain the TLB state so it's not being re-enabled quickly enough. This crashes can happen when loading a save state and then pushing that start button.
This was a game crash, not a core crash, in game screenshot:
I forced using_tlb to 0 in the code but couldn't reproduce the issue. Do you have the savestate when the problem occurs?
BTW once set the using_tlb flag is only cleared on core shutdown, is this happening when using the resume option in mupen64plus-ae?
Yes, this is happening during the resume option. I can't seem to repeat it consistently, only sometimes. I'll see if I can find a way to make it happen more often.
Damn I hate this resume option, we need to find a way to make it more predictable, for example only do a loadstate on first frame. This is what the --savestate option is doing btw.
Why are we using M64CMD_STATE_LOAD instead of --savestate for resume? Any idea? It would be very easy to change to --savestate instead.
Also, is the "slot" functionality doing it correctly?
The drawback of the --savestate option is that the first frame will be shown before the loadstate happens. I think @littleguy77 wanted to avoid this.
Also, is the "slot" functionality doing it correctly?
What do you mean?
You know how we have the option to save and load states using slots? I mean saving and loading using that functionality.
You can't load slot using the --savestate option. You need to specify the path to the savestate --savestate C:\save.state
Otherwise you can set your own frame callback coreDoCommand(M64CMD_SET_FRAME_CALLBACK, 0, (void*)MyFrameCallback) and do whatever you want inside it. You'll have to wait before M64CORE_EMU_STATE changed to M64EMU_RUNNING using OnStateCallbackListener before setting the callback.
I'm not saying that this will fix the issue. However with the --savestate option, the loadstate will always happen at the same moment, so if you manage to reproduce the issue once, the crash should happen every time you try to resume the corresponding savestate.
It's just that I won't be able to fix the issue if it's not 100% reproducible
The implementation is pretty simple:
if( !sIsRestarting )
{
arglist.add( "--savestate" );
arglist.add( saveToLoad );
}
and remove the whole block after the // Auto-load state if desired comment.
We still have to find a way to avoid showing the first frame before the loadstate happens.
You can test with dk64, the nintendo logo will always be shown before the loadstate happens.
@richard42 I'd like to change the --savestate option implementation. The idea is to load the savestate on the first safe state interrupt instead of loading it on the first frame. Do you think this is an acceptable solution?
Code here: https://github.com/Gillou68310/mupen64plus-core/commit/46654f26c927d2863d58680708ac7ed5c704f1e6 https://github.com/Gillou68310/mupen64plus-ui-console/commit/334db80b5559709905bd150b5f20fbf4c4005f49
I added the --savestate at startup option for my regression test framework (yet to be published):
https://github.com/mupen64plus/mupen64plus-ui-console/commit/566c9f9903592a1bda9a1e3f299537cb7027d9ac https://github.com/mupen64plus/mupen64plus-ui-console/commit/7d5247b3990a5b8232fb717af43355d10a2a3561 https://github.com/mupen64plus/mupen64plus-ui-console/commit/c495ff81e68a45b7c703629c20b88a5a56031a9f
The point is to work like this:
- Load the state
- Wait a given number of frame
- Do a screenshot
- Quit
The command is generated by a python script like this:
cmd = ["./mupen64plus",
"--resolution", "640x480",
"--audio", "dummy",
"--configdir", os.path.join(current_dir, "config"),
"--nosaveoptions",
"--testshots", ",".join((str(f) for f in frames)),
"--savestate", os.path.join(save_state_dir, "%s.st0" % test_name),
"--sshotdir", tmp_screenshot_dir,
rom_path]
I saw your code and it should work fine. I will try it asap and keep you in touch. :)
I just tested. For an unknown reason, I have a black screen or no texture using --nosaveoptions with rice. mupen64plus-video-glide64mk2 doesn't seems to have any problem so I guess there is a problem with Rice options.
Anyway, It's ok for me. I suggest to do PR. :)
It's supposed to be a core option to do not save mupen64plus.cfg. I don't really understand why it create some troubles with rice.
Sure, I'll check it out. This was not 100% reproducible, so it will be hard to 100% verify. But I will keep playing through Paper Mario and see if it happens again.
Ok, I just had the in-game crash again after including the change to ui-console and the core. When I tried to manually load the saves state that caused it, it didn't crash... It's frustrating to reproduce the issue since it's so inconsistent.
Did you change the resume implementation in m64p-ae to use the --savestate option?
Ok, I haven't had it happen when resuming yet. But I just had it happen during a slot save. Here's is the slot save, just load it and push the N64 start button.
And saving a state in this condition causes a corrupt save state that causes the core to crash when being loaded:
2016-10-23-07-06-57.v2.sav.zip
Ok, upon restarting the app and loading the save state. The game no longer crashes.
Also I couldn't get the app to stop crashing until I deleted all game data. I should have captured the core dump.
Ok, I just had it happen after using the --savestate option. Once this in-game crash happens, it doesn't matter what states I load. Only way to recover is to kill then restart the app and I'm able to load the save state just fine and get into the in-game subscreen.
This crash only has happened after entering the in-game subscreen. To me, it seems that somehow TLB is not being activated sometimes.
Next time this happens, I'm going to try restarting by using reset, and see if it continues to happen.
Edit: Just happened again, I did a reset so the game would start over, loaded using the in-game save to load, then got into the in-game subscreen, and there was no crash. I think this confirms that TLB is not being enabled when loading a save state.
Why can't we save the TLB state as part of save states?
Ok I confirm that this bug is caused by the using_tlb flag. When loading the first savestate you provided using the --savestate option I'm getting the issue 100% of the time.
Initializing the using_tlb flag to 1 fix the issue.
So like you said, the only way to fix this issue is to add the using_tlb flag to the savestate.
@Narann, @richard42 is the following solution ok for you? https://github.com/Gillou68310/mupen64plus-core/commit/22aa4f41b2c0354b260824a43d433ae3de81266f