Retroarch: Save/load states cause code dump/black screen

Created on 2 Jun 2016  ·  22Comments  ·  Source: libretro/RetroArch

I don't know if this is yet another waste of your guys' time, given my track record with "bug" reports that end up being either unable to be reproduced or something on my end, so I figure I'll post them anyway, might be useful, probably not.

Starting in version 1.3.0, save states fail to be operative/functional. Deleted all configuration files and started fresh, got everything set up, proper directories and so forth, loaded up Snes9x Next and Seiken Densetsu 3, and Super Mario All-Stars, just for the sake of quickly testing them out. The menu still requires pressing Home twice in succession, but it loads fine. In fact, during the set up, no errors or crashes, but when saving states, the emulator locked up on 1.3.0 and had a code dump* on 1.3.4, both vanilla versions. No nightly builds were used during these tests.

*The code dump timed out after eight seconds, so I couldn't take a screenshot of it with a camera.

Anyways, RetroArch 1.2.2 and 1.0.0.2 had function save/load states, and were the last two versions to actually work with them. But since 1.3.0, and beyond, they are completely broken, hell, I don't even know if they'll ever be fixed now that people are moving on to the Wii U and losing all interest in improving the Wii port, I don't know.

1.3.0 - Locked up with code dump, returned to homebrew menu after eight second timeout
1.3.2 - Same as above, complete lock up of system and black screen.
1.3.4 - Black screen/complete lockup of system, had to hard reboot (tested on Wii U Wii Mode, not Wii).

This is all the info I have, deleted all config files, started fresh installs, using 1.3.0 through 1.3.4 and all have inoperative save and load states. Yes, native in-game saving is more stable and as I always use that more than save states, however, if they are broken in the Wii ports, then the feature should be removed as they are rendered useless to those who use them, am I wrong?

major needs info or confirmation wingc

All 22 comments

I could maybe invite @netux79 in this thread to see if he has any idea.

Okay, that works, as this is very baffling to me, as 1.2.2 worked just fine with them.

Made a thread on the forums, not sure if it'll do any good though. Heh. Should I record footage of me encountering the error?

No need for the video... looks pretty clear how it is crashing... I will take a look tomorrow and let you know what I find.

Wasn't sure at first, but it seems it's a pretty serious issue, why the Wii port is affected and not Android is baffling. Okay, I'll keep a lookout.

I tested 1.3.4 and I was able replicate the issue. However I should say that this is only present on snes9x-next, all other cores are working fine. In fact snes9x (not the next one) core is able to use save states correctly on Wii. So I wonder if this should be an issue of snes9x-next instead of RA itself.

As snes9x-next is able to save and load savestates in PC version (Win and Linux) I think this might be something related to the Big Endian.

@netux79 Where do we go from here? Right now I'm using Snes9x Next on RetroArch 1.2.2 and it's working perfectly, so yeah, something did break. In the mean time, I'll keep using 1.2.2 as it's the most stable for now.

Edit: Rewrote my message, sorry about that.

@roflcopter777 While I understand it is unfortunate this no longer works and it should indeed be looked at, please keep the whining to an absolute minimum here unless you have an actual intent to help out in the development process, because this is not productive at all and all it will do is make people stressed out. I know it does for me at least. And in the end, the guys who care the most should build themselves up to the point where they can do more than just whine. Everybody can learn to program, those who feel most passionate about it should take the lead.

@netux79 Regarding the actual issues - I think there were some patches people committed for Blackberry and other platforms to prevent the savestates from crashing, it might be related to those. I'll start linking to some of these issues in hopes we can figure out how to fix this issue.

@twinaphex My apologies, I had assumed the Wii port was being diverted for other ports with higher priority, esp given that the Wii U now has full PPC kernel exploit/access (but that's for another topic, if that's even allowed IDK). Thank you for replying and I'm not exactly sure what I can help test. Nightly builds perhaps?

@twinaphex : were these patches comitted to Retroarch or to snes9x-next?

Yeah, if I recall correctly, GCC has a habit of optimizing the S9xAPULoadState/S9xAPUSaveState function to the extent it actually breaks them. It affected other platforms as well.

See this commit -
https://github.com/libretro/snes9x-next/pull/23/commits/51d73e4b2d174b7b72141f7aa72f6ca497c17d56

Maybe there's something related going on.

I see, however that commit it's from a long time ago... what I will do will be to build RA with a previous version of snes9x-next and see how it behaves... I think I have an idea what could be wrong... it is an issue from around year ago when 1.2.2 was released.

OK, let me know when you find out more, and thanks in advance for looking into this.

Huh, interesting, using 1.2.2 right now and the save state are working on that very core.

@roflcopter777 If you are not compiling from source. that doesnt mean anything. Libretro cores are not dynamically linked on Wii, they are statically linked at compile time. So what you are testing most likely is just an older version of snes9x next with an older version of retroarch.

Please dont spread confusion in this topic and just take a backseat while we try to sort this out.

I found the issue and fixed it. As I said it was a snes9x-next issue... @twinaphex was right, it was related to optimizations. However it didn't worked to do the optimization to the single savestate functions. I had to make the whole core O2 optimized.

What happens now?

You can wait for the next build and try for yourself and then let us know.

Will do

Just FYI - O3 also breaks some games on the RPI - so we also build with O2 for RetroPie - https://github.com/libretro/snes9x-next/issues/50

I've also experienced lock-ups on wii every time when savestate autoloading was enabled with the 1.3.4 release of vba-next. Could -O3 also be the reason here, or is this another issue altogether. incidentally, with current wii nightly builds of retroarch the auto save/load functionality seems to do nothing with any core. At least states never get auto loaded anymore when starting a game.

Are you using retroachients hardcore mode? It disables save states.

On יום ד׳, 22 ביונ 2016 at 14:46 pantra64 [email protected] wrote:

I've also experienced lock-ups on wii every time when savestate
autoloading was enabled with the 1.3.4 release of vba-next. Could -O3 also
be the reason here, or is this another issue altogether. incidentally, with
current wii nightly builds of retroarch the auto save/load functionality
seems to do nothing. At least it never ever auto loads states anymore when
starting a game.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/libretro/RetroArch/issues/3053#issuecomment-227719620,
or mute the thread
https://github.com/notifications/unsubscribe/AAIb6zBp2XD2JYS3wggL_WjikAAEtyLaks5qOSCcgaJpZM4Is_7o
.

@yisraeldov No, not that I know of. Do I have to set cheevos_hardcore_mode_enable = false or isn't that the default anyway? Also, manual saving and loading does work. Only auto saving/loading doesn't seem to do anything anymore.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

orbea picture orbea  ·  3Comments

fr500 picture fr500  ·  4Comments

parkerlreed picture parkerlreed  ·  3Comments

GoronMegaZord picture GoronMegaZord  ·  3Comments

charlydelta picture charlydelta  ·  3Comments