That’s fine, complete hash is 40 characters long, so only the first few are shown in RA’s menu, and i’m never sure how how many exactly. You are using latest version of the core, and it still seems to crash at the first attempt to write something in the tmpfile.
Buildbot is building the cores then sending them to the online updater, so updating from the buildbot basically means the same thing as using the online updater.
I just pushed another commit (hash is a58d346, as usual, it should be available from the online updater “soon”), this one contains new logs to double check it’s really crashing at that first write attempt, and also an attempt at fixing this by using another writing method, i’ll be waiting for the new logs and/or the news that the issue somehow got solved by changing the writing method.
I don’t see hash a58d346 after updating. It’s still 145e7dc…
Yes, it’ll usually take more than 20 minutes for the new core to be available from the online updater, try again later.
It’s been over an hour and I’m still not able to update the core…
It’s updated. Okay, here is the log:
The good news is that we passed the first crash, the bad news is that it crashed later. Long story short it seems your system crash every time it encounters the fprintf function for some reason, but it seems we can get around this issue by using another function called fwrite.
I pushed another commit to try to fix this (will be 3980e76 i think ?), let me know how it turns out when it’ll be available from the online updater.
Here is the log. It doesn’t crash at save state now but now it doesn’t save a state at all. I get a message saying : “This core doesn’t support save states”.
Yeah, i noticed this afternoon that we never checked if the tmpfile was created or not before trying to write on it, because as far as we knew there was no reason for the OS to reject creating tmpfiles, it turns out we were wrong, apparently your setups won’t create tmpfiles (and i’ve still no idea why), and the crash happened because we were trying to write on that non-existent file.
I intend to rewrite the savestate code in Kronos in the next few weeks, so that it doesn’t rely on tmpfile creation at all.
That would be great thank you! If you update Kronos will the other Saturn cores be updated as well like the Yabause core?
I intend to backport the “fix” that check if the tmpfile is created to Yabause, nothing else.
Sorry I hadn’t seen your post… Core is latest version and using Kronos, not “old”, I just thought I would try a random setting “share save states with Beetle”… but still insta crash on save state.
Kronos standalone saves state fine but I can’t get any game to boot once controller settings are done (same with Yaba standalone). I have nothing but nightmares with the standalone of both so I deleted them both.
I will do what you asked sometime today… where is that log even located?
Edit: I just enabled core logging to 0, loaded the game in Kronos, tried to save state and crash of course, and now I went into a folder called “logs” in retroarch and it’s completely empty.
[BarbuDreadMon] “I intend to rewrite the savestate code in Kronos in the next few weeks, so that it doesn’t rely on tmpfile creation at all.” I intend to backport the “fix” that check if the tmpfile is created to Yabause, nothing else.
So which core are you rewriting the savestate for? Kronos core or Yabause core?
I’m working on the Kronos core, and while i backport some stuff to the Yabause core from time to time, i only does it for simple ones.
The only way I know how to update to the latest version of the core is through retroarch.
Edit, ok the crash is fixed but I get the message “Core does not support save states”.
When i say to read my post above, that’s because i want you to read it…
I read it, then I read the one where you told me to read it… I got confused cause when you said the crash was already fixed, to ME that reads that the problem has been fixed. So on one hand I thought you were saying it would be a few weeks and on the other that it was fixed already. I was simply reporting.
As already explained the issue is that your setup refuse to create tmpfiles (probably some shitty rights issue, i wouldn’t be surprised if executing RA as admin was a workaround), and that’s why it was crashing when trying to write on that tmpfile. Now the savestate process properly stop if your OS refuse to create the tmpfile.
As for the complete rewrite of the savestate process to avoid having to use a tmpfile, it’ll take time, weeks, maybe months, because tbh i have other things to do.
Okay, so you’re fixing/rewriting the Kronos core so anyone with a SSD can make save states. Got it. Thanks again for doing this!