Is there a way to quickly check the savestate/ROM is working or not ?

[steward-fu]

Reverse DraStic emulator to find out some useful functions for quick testing.

[Sichroteph]

First, I am not sure these freeze can be 100% prevented. If you had a way (file size, or maybe a bit presence in the file) it could come in handly for 1) unfreezing drastic or prevent it to load it 2) maybe load a state backup instead (for the auto load on boot feature)

[steward-fu]

Could you please attach both the corrupted savestate and the normal savestate files on this issue. Thanks

[Sichroteph]

I don't have any but we will ask for them when an user is experiencing this.

[steward-fu]

For the first stage, I think I can remove the sigterm() for Onion system and then restart the game if the rendering function in SDL2 library doesn't be called by drastic emulator for a period of time (ex: 3 seconds).

[Sichroteph]

That seems a great idea 👍 As soon as the binary is ready we will publish an hotfix. Thank you.

[Sichroteph]

Initially, the 3-second timer isn't essential; I'm optimistic that deactivating the handler should suffice. With the timer there's a risk of introducing new bugs that could result in the player losing progress. For instance, if the screen is turned off right after launching Drastic, the process is suspended, but the clock might not be.

[steward-fu]

@Sichroteph Here is the test build: https://drive.google.com/file/d/1ENpXHI_e0-YHH5oAFB8asEyiOXJesrEt/view?usp=sharing In this test build, I only disabled sigterm for test. For the corrupted savestate, I think we need know the file format of savesate and then we can check why the are corrupted.

[schmurtzm]

Thank you ! Here one corrupted savestate which trigger a white screen. And here another one on the same game which is working.

[Sichroteph]

@steward-fu Thank you for providing the test build. Nevertheless, it still responds to sigterms, and it required two attempts to corrupt a savestate using the "kill -TERM {pid}" command on telnet. Here is the corrupted state it made. https://drive.google.com/file/d/1RVMtuZVqKPjRJ8aJ396UEx-kf8BZh5yX/view?usp=sharing

[Sichroteph]

@steward-fu We conducted tests internally and have concluded that preventing the arrival of the sigterm to Drastic appears to be impossible. Nevertheless, could you explore the possibility of preventing a state from being created when the sigterm arrives on your end? In such a scenario, drastic would exit without saving anything. However, please note that exiting through the menu/button shortcut would still result in the creation of a save state. Do you believe this is a feasible solution?

[steward-fu]

I can use a new flag for such scenario. Set this flag as false if the sigterm() is triggered. Set this falg as true if the hotkey is pressed.

And finally, when SDL2 library is exiting, we can decide whether the svaestate is needed or not.

[steward-fu]

I created a new branch for this issue (corrupted_savestate) and added the a new flag to handle sigterm: https://github.com/steward-fu/nds/commit/3808bf4d77e33b5cb508f998cf0d0f1af4abe425

When SDL2 gets a termination signal, it calls set_sigterm_flag() in alsa library to set this flag. The savesate file (xxx_10.dss) won't be created if this flag is set as non-zero when drastic emulator is exiting.

[Sichroteph]

Thank you! We've made some adjustments to our keymon as well, such as avoiding the sending of multiple exit commands and extending the waiting time to more than 8 seconds for drastic to exit. We hope these changes will address the auto sleep issue your users have been experiencing.

[steward-fu]

If so, do you think we still need disable sigterm() function and stop writing savestate file (xxx_10.dss) if the sigterm is triggered.

[Sichroteph]

Let's see feedback from our users :) If the current build is sufficiently stable, there might not be a need to make further adjustments. You've already put in a lot of effort into this.

[steward-fu]

If this issue doesn't exist anymore, please help close this case, thanks in advance.

[Sichroteph]

Sure you can close this case (I don't think I have the rights to do so, since you created it) Thanks !