0

I want to implement a feature, that when my application crashes it saves the current data to a temporary file so it can be recovered on the next launch like many application do (eg. Word or something).

So as far as I could find out this is typically done by just saving the file every few minutes and then loading that last saved file on startup if it exists.

However I was wondering if it could also be done by catching all unhandled exceptions and then call the save method when the application crashes.

The advantage would be that I don't have to write to the disk all the time, cause SSDs don't like that, and the file would really be from the crash time and not 10 minutes old in the worst case.

I've tried this on linux with

signal(SIGSEGV, crashSave);

where crashSave() is the function that calls the save and it seems to work. However I'm not sure if this will work on Windows as well?

And is there a general reason why I should not do this (except that the saved file might be corrupted in few cases) Or what is the advantage of other applications doing timed autosave instead?

goaran
  • 353
  • 2
  • 11
  • 2
    This is not going to work, see [this question for more information and a detailed explanation](https://stackoverflow.com/questions/63770819/when-signal-handler-is-not-called-when-segment-fault-occurs/63770937#63770937). As I wrote in that answer, when a bug results in a segfault, the correct fix is to figure out what the bug is, and fix it. Attempting to clean up, after the fact, using a signal handler, will only end in tears. – Sam Varshavchik Sep 10 '20 at 22:37
  • 1
    Once a crash has already occured, you don't know what state your program is in anymore, so trying to save your state data at that time is risky, as the data itself may have been corrupted. So, that is why it is best to save your state date periodically when you know your program is still in a good state. – Remy Lebeau Sep 10 '20 at 22:40
  • In addition to the above, there's not that much you're allowed to do in a signal handler. You can't even safely print out a message screaming for help. Saving a recovery file's very unlikely to succeed. [Here's a list of what you can do in a POSIX system](https://www.man7.org/linux/man-pages/man7/signal-safety.7.html). – user4581301 Sep 10 '20 at 22:42
  • A good idea is to emit information to a log file periodically, with timestamp. This will give you a history of behavior which is very useful when debugging. – Thomas Matthews Sep 10 '20 at 22:42
  • For Windows, you can utilize [crash dumps](https://stackoverflow.com/questions/2237017/post-mortem-crash-dump-debugging-without-having-the-exact-version-of-a-windows-d). But as others mentioned, the state of your program when the crash occurred is unknown. The crash dump can tell you *where* your program crashed, but trying to perform tasks such as saving files, etc. is not going to go too well. – PaulMcKenzie Sep 10 '20 at 22:43
  • @SamVarshavchik: of cource the best way is to fix the code, and for every bug I know about of course I fix it. However for a large project there is no chance that you can say it is 100% bugfree. You can get close but never will reach it. So just for these cases a file recovery still makes some sense I think, @R – goaran Sep 10 '20 at 23:07
  • @RemyLebeau ok, I know the data may be broken at that point, but at that point we are already at the state where the application crashed, so saving at least some date (taht might be somehow wrong in some cases) is still better than saving nothing I think. – goaran Sep 10 '20 at 23:10
  • @user4581301 thanks, for the link with the allowed things I can do in the signal handler, I'll have to check what exactly my save function does there. Since in the test I did the saving from the signal handler seems to work well, just a maybe stupid question: What could go wrong there in the worst case, because the application already crashed, and it can't crash even more, or may there be some other problems then? So in the worst case the recovery file would be corrupt? – goaran Sep 10 '20 at 23:21
  • 1
    The worst case would be crashed application ending up exploiting a bug in your operating system to reformat your hard drive. Anything can happen as a result of undefined behavior, and the answer that I linked earlier gives a not so implausible situation where that might happen. – Sam Varshavchik Sep 10 '20 at 23:27
  • @SamVarshavchik, Ok, thanks, you convinced me, that it's a bad idea. Thanks for the explanation. – goaran Sep 10 '20 at 23:34

0 Answers0