[Bug] Sstate corruption bug

[Air]

If the savestate were incomplete, the error would have been a native Win32/C++ exception and a failure to load the savestate, complete with a message describing the corrupted section of the savestate. Trap exceptions indicate that the savestate loaded fine, and that the core of the emulator is flawed somehow.

The size of the savestate has nothing to do with the crash. Nearly the only thing that can cause that sort of variety in savestate size is the GS plugin (GS memory makes up the large bulk of the savestate data in most cases) -- and this size can vary greatly from frame to frame of a game.

The crash is most likely related to something in the DMA controller not being saved out at all (in any savestates, working or broken); as thats the most likely source of end-case (rare) crashes. Furthermore, games almost exclusively use Trap instructions for highly unexpected DMA controller statuses (and not much else). What happens is that the DMAC is fully functional with arbitrary or default values for like 95% of all games. Only a few games end up having semi-random crashes if some of those status vars get lost during savestate save/load.

[Air]

devs don't take requests.
but as this is an open source project, you can bring your piece of code at http://code.google.com/p/pcsx2/

I dont think, that renamеing old file into filename.bak, before writing new one is need huge pice of code.
But, if devs dont take requests and dont pay attention to this problem, this thread is useless.

There are a few problems here. I shall go over them in detail.

1) PCSX2 provides a manual way to avoid this problem. F2 and Shift-F2 cycle savestate slots. You have ten slots for every game. You can easily cycle a few slots and avoid this problem yourself.

The display mechanism for knowing the current slot is not ideal, but I've used it quite successfully -- as do many other folks. I never overwrite my previous savestate .. I always cycle at least slots 0 and 1, just in case.

2) Making automatic backups would double my own savestates folder size from ~488mb to 1gb, and I don't actually get to use the emulator half as much as other people (too busy working on it). And some games can have upwards of 25mb states. This is a lot of bloat by most of our users' standards, so if I'm to implement this feature it needs to be properly toggleable in config somewhere. The toggle and config entry stuff is probably 4x as much work as the actual backup.

3) Passive aggressive attitude will not help you get what you want. I work extremely hard on this emulator, and I have a thousand things on my todo list. Many of them are as 'easy' as your request. Should I put yours to the top of the list? Or maybe the next request after yours I'll put up there, just to infuriate you. There's no harm in infuriating people who are otherwise useless anyway, I figure.

Personally, I prefer to work on the hard stuff that few other people have the knowledge and experience to implement properly. Meanwhile, I hope (quietly) that other people will help supply code for some of these easier things. But guess what? No one ever does. So don't cry me a river.

[Shadow Lady]

2) The idea of automatic backups is so it rename/copy the savestate that's going to be replaced and not all of them so it would only add one savestate and not double all of them. This would also be a way to avoid having to cycle between slots and you'd just have to load the .bak or whatever the last savestate was renamed to.

Problem with this is people loading and making a new savestate just seconds after making another one might just screw it again

[avih]

Maybe it can be made to auto-cycle between slots 0/1/2 ? or even just have a SS-backup checkbox that would use slot 9 for the backup? or even slot 'backup' only for this usage? On any of these cases, saving directly to the backup slot(/s) should not be possible.

It won't solve the problem if the previous SS can't load either, but it might still be better than nothing.