I remember seeing some bilinear filtering setting in RetroArch (not the cores because post-processing is considered the role of the frontend), but i believe shaders (another form of post-processing) are far more popular.
I added more logs, same mission as last time, post the logs from the crash, and don’t forget to set “core logging level” to “debug”
Okay here is the new log. Still crashing just like before…
For now i’m just trying to figure out why/where it’s crashing on your setup, your last logs made it clear that it’s crashing in the YabSaveStateStream function, which basically means “sometime when writing something to the tmpfile”, it further confirm my suspicions about this being a “writing on ssd” issue. I added more logs to locate the crash more precisely, your mission will be the same as before.
Okay here is the new log:
Are you sure the core on buildbot was updated before you made that new log ? I don’t see any of the new logs i added. What’s the commit hash at bottom left corner of retroarch menu ? It should be 145e7dc3b or something like that. If that’s really made using the latest version of the core, then it means it crashes on the very first write attempt to the tmpfile, confirming there is indeed an issue with that tmpfile handling on ssd.
I tried updating the cores and now it’s at 145e7dc3b. Here is my log file: Is that right?
Actually never mind I’m getting a commit hash of 145e7dc. What do you mean by updating the core on buildbot? I updated my cores through the online updater in Retroarch. Is there something else I’m supposed to be doing?
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.