RetroArch crashes when saving states

[klepp0906]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

RetroArch crashes when attempting to save states. Figured it might be core related so tried a different core, no good. Figured it might be the fact that im loading from an already saved state so tried with a blank slate, no good. Figured it may be due to gpu screenshot being enabled, but on or off makes no difference. Finally swapped from vulkan to glcore to test. Unfortunately it still crashes.

The save gets off/saves properly, but retroarch freezes and hard closes immediately/simultaneously.

Expected behavior

Save states to function as they always have of course :)

Actual behavior

This section is kind of redundant.

Steps to reproduce the bug

1. Load content
2. enter the quick menu and save a state
3. feel great pangs of sorrow as you look at your desktop

Bisect Results

Unfortunately the last i played and saved was a few weeks back, so I cant say for sure when it began happening. I update every few days at worst. hunterk mentioned that savestate compression was added recently and may have a hand in it.

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.8.5 c88ffa56ff

Environment information

• OS: Windows 10
• Compiler: buildbot

[klepp0906]

just tried about a bazillion more things. replaced the nightly exe with the 1.8.5 stable exe and it works fine. so something between then and now.

[klepp0906]

going back day by day the one from April 22 is the first to work

62c2842c86

[i30817]

Someone with this bug better do a proper bisect/debug because that commit isn't it.

I can save and load savestates from the libretro-uae core, for what it's worth (not that much, not sure if it uses saveram).

edit: doh, i haven't built RA in a while.

[klepp0906]

May not be that commit persay. I’ve only done a legitimate bisect once with msys and a developer held my hand the entire time. Was ages ago.

I was only able to pull nightly builds from the buildbot and going day by day backwards until I hit the first to work.

That was simply the build number inside said nightly (from the 22nd)

If I understand commits correctly, there would be sometimes several or more between days. All I can say is it was something between the 22nd and 23rd nightly as 22 works, 23 and after does not.

I’m ingesting my coffee now so if I can be of any further help, by all means.

[i30817]

You better drag and drop your retroarch.cfg and retroarch-core-options.cfg files into a post here for us to be able to see the settings. I just tried a recent build, saved the state on psx Alundra, and loaded it back with no problems. Though i had all those compression options off.

Also check that your savestate dir on the cfg exists and is writable.

[Sanaki]

If you use retroachievements, always clear out the values on cheevos_token and cheevos_password before showing anyone your retroarch.cfg. Same for youtube_stream_key and twitch_stream_key if you use those.

[klepp0906]

oh yea, i dont doubt its something potentially related to some other setting. tantamount to ppsspp crashing on states but only if bgm/mixer AND pause in menu are enabled. (that one was a doozy to hunt down)

[klepp0906]

will get ya the core options momentarily. and yes the save state dir is unchanged. It writes the saves fine. they work and everything. even the thumbnail/screenshot of them updates. It just takes RA down with it.

also tried with 3 different cores, beetle psx, gens plus, and ppsspp and all 3 exhibited the same behavior so unless im extraordinarily unlucky, i dont believe its core related.

[i30817]

I tried to enable savestate compression and savestate images but couldn't reproduce. I noticed that you're on windows and i'm in linux, might influence the crash. Are the files being written to the savestate dir, even if incomplete? (i noticed you used :\states which i'm guessing is the windows version of 'root of the current drive\states'). Maybe it's possible the retroarch process 'current dir' isn't on the root you expect it to be and the states dir doesn't exist where it's at?

Does it happen to you on the beetle hardware core (it's the one i tried)?

[klepp0906]

yes, i tried with compression on and off as well as hunterk noted it was added recently so i thought it may have had a hand.

also yes, the savestate dir is the default. root of RA dir > states > core folder > .state files

wouldnt be the first time a bug showed on windows that didnt on linux :P

[klepp0906]

Does it happen to you on the beetle hardware core (it's the one i tried)?

yes, thats my primary core as of late. Definitely happens with the newest beetle psx hw

[i30817]

Ah i was mistaken, i thought that :\ thing was for 'root of the current drive' not 'current retroarch dir'.

[i30817]

but try it with fixed, existing, writable directory, such as "C:\states" (make sure folder states exists on c), to see if something happens.

Maybe it's a antivirus interfering, i also hear those cause problems with writes on 'unauthorized dirs' sometimes..., if you have a antivirus running, check if it had alerts for those dirs when RA crashed.

[klepp0906]

just using baked in windows defender. i dont run retroarch on my system drive so i dont believe it touches non system disks. Even so to be sure i set all my non system drives as exclusions.

still in the sake of being thorough ill turn it off and also try to change the save state dir RQ to look for any change.

[klepp0906]

mmm. well i disabled defender, changed the state save location to a new folder on a new drive.

result is the same on current build. Fling back to the 22nd and its fine again.

[i30817]

Yeah, i got nothing, someone with windows will have to try it with your configs and debug the crash. Good luck.

[klepp0906]

nbd, i appreciate you putting any time into it at all.

ill be hammering on it all day after i get back from the gym. sort of thing i cant move past even if it werent central to RA anyways.

I dont like things "not" working coupled with some relatively strong OCD. Imagine my plight with a tech hobby lol.

[klepp0906]

just figured id update. still stuck on the build from the 22nd. tried todays nightly, result is the same.

would logs help?

[bslenul]

OK, I'm able to reproduce, and it's for a super weird reason: widgets :x
If I disabled them, my RA crashes too on save state.

edit: Hm, seems to be a combination of settings (idk which ones yet tho...), if I disable widgets on a fresh retroarch.cfg it doesn't crash.

edit2: Seems to be widgets OFF + states thumbnails ON, I'll do some bisecting now that I know how to reproduce.

[klepp0906]

HA. go figure. and i did disable them. I'm using/prefer the old style. Question is what changed with widgets between the 22nd and 23rd then.

thank you VERY much for testing/dialing in on that. It likely woulda taken me quite some time to get down to looking at widgets LOL.

always has to be something weird to make things difficult. As i was discussing earlier, the ppsspp core has an open issue regarding crashes if you enter/exit the quick menu but only if you have mixer enabled and pause when in menu enabled together. oddness.

[bslenul]

Bisect done (it wasn't very long thanks to the commit mentioned above :D ), looks like 89c405b196403f1bf37dbfde82447f4f2a6e0e80 is the guilty.

edit: Windows 10 btw, the crash doesn't seem to happen on my Linux VM with widgets OFF + states thumbnails ON.

[jdgleaver]

@bslenul I don't have a Windows machine and so can't reproduce this (no crash on Linux, as you say!), but there are definitely some shenanigans in the screenshot code. Would it be possible for you to test this diff on Windows, applied to current master?

diff --git a/tasks/task_screenshot.c b/tasks/task_screenshot.c
index f1a34deb3a..138c8ae48e 100644
--- a/tasks/task_screenshot.c
+++ b/tasks/task_screenshot.c
@@ -165,7 +165,10 @@ static void task_screenshot_handler(retro_task_t *task)
          is displayed */
       if (!state->widgets_ready)
 #endif
+      {
          free(state);
+         task->state = NULL;
+      }
       return;
    }

@@ -209,15 +212,21 @@ static void task_screenshot_callback(retro_task_t *task,
       void *task_data,
       void *user_data, const char *error)
 {
-   screenshot_task_state_t *state = (screenshot_task_state_t*)task->state;
+   screenshot_task_state_t *state = NULL;
+
+   if (!task)
+      return;
+
+   state = (screenshot_task_state_t*)task->state;

-   if (!state->widgets_ready)
+   if (!state)
       return;

-   if (state && !state->silence && state->widgets_ready)
+   if (!state->silence && state->widgets_ready)
       gfx_widget_screenshot_taken(state->shotname, state->filename);

    free(state);
+   task->state = NULL;
 }
 #endif

@@ -341,7 +350,8 @@ static bool screenshot_dump(
       task->state       = state;
       task->handler     = task_screenshot_handler;
 #if defined(HAVE_GFX_WIDGETS)
-      task->callback    = task_screenshot_callback;
+      task->callback    = state->widgets_ready ?
+            task_screenshot_callback : NULL;
       if (state->widgets_ready && !savestate)
          task_free_title(task);
       else

[bslenul]

Yup, no crash anymore with these changes! 👍

[jdgleaver]

Great, thanks for testing!

Save state thumbnails have been iffy for a very long time, and no one could work out why - never would have caught this without you providing the exact crash conditions :)

I'll PR the changes later today

[bslenul]

Awesome, glad I could've been useful :p Thank you for the fix!

[jdgleaver]

Okay, should be sorted once this gets merged: #10542

[klepp0906]

you guys are the best. truly. I appreciate it very much!

[klepp0906]

worth mentioning (since this hasnt been merged yet) that i updated to the newest nightly before i checked if it had been merged or not.

I didnt even get around to testing the save states (which would have indicated it was not merged anyways) but I did try to record some video as I was working on a ffmpeg.cfg. turns out thsoe insta crash on the newer builds too, but not on the 22nd that im using.

unsure if its related but id assume so. not sure if your fix will apply there as well?

[jdgleaver]

worth mentioning (since this hasnt been merged yet) that i updated to the newest nightly before i checked if it had been merged or not.

Odd... The PR was merged 4 days ago. It seems the buildbot might be having some issues (the Android nightlies are stuck on an old build as well) - hopefully this will resolve itself...

I did try to record some video as I was working on a ffmpeg.cfg. turns out thsoe insta crash on the newer builds too, but not on the 22nd that im using.

unsure if its related but id assume so. not sure if your fix will apply there as well?

This is 100% unrelated to the issue that was resolved here :)

It's actually really hard for me to debug this - I can't get ffmpeg support to build at all on my dev machine, and only managed to get it to work on an old laptop - where it worked just fine (no crashes, under Linux at least).

So this is most likely something in your custom config file...

Also, does the directory to which you are recording actually exist? I've heard reports that crashes can occur if it doesn't (but I don't use recording myself, and as I said, I can't debug this stuff on my dev machine)

Either way, you should open a new issue for this!

[bslenul]

Odd... The PR was merged 4 days ago.

The day after your PR the fix was in nightlies, it doesn't crash for me anymore. But yeah there's something wrong with the buildbot, I still don't have the "Mute when fast forwad" feature you added recently for example.

[klepp0906]

thanks for the replies gentlemen. After waking up to the email notification about your posts, I just updated again. got 1.8.6 this time and everything seems to work now so yay for that.

i always tell you guys words dont do you justice. nor does a means exist to properly express my gratitude.

[jdgleaver]

Ah, glad that's working now :)

The buildbot is still a bit iffy, but it's under heavy load at the moment - hopefully in a day or so it'll catch up with itself!