1) Best thing to handle crashes is to fix the cause of the crashes.
Now you tell me
Feel free to fix some bugs, but you'll never get the last one. In a project as complex as CB, I can promise you that.
libgtk-2.24.23-0ubuntu1.4, Mint17, ~180 files, code completion has several problems with the macro-infested code (as I've mentioned in the first post, the problem most probably stems from a realtime code scanner), crashes are never hangs, I usually don't start it from the console - but the errors were never the same and usually wx-related (sry about the lack of detail here, but I gave up on narrowing in on those errors years ago)
Sorry, that I can't provide the source samples or core dumps. The sources are not open and the decision to change that is not mine to make.
2) On not loosing data without autosave: Have you a idea how this can work technically? How can we be sure that the data in the editor is not corrupt? How can we not know that the editor is not the source of crash? This is fully technical question. I never informed me about crash recovery...
I do that in own projects. Catch the signals (from the operating system, where it is informing you about the crash) and write as much data as useful and possible. Write as much as is known about the state to the console, so that the crash cause can be narrowed in on - and write all data, that otherwise would be lost to a special directory. While doing that, you should trust as little existing data structures as possible (which is why the data should go to a new and empty directory, so that no other data is overwritten). The only technical difficulty of that is, that the signals are realtime interrupts and therefore can catch your data structures in any intermediate state. But since you're not going for the last checkbox state and window position, it is still a fairly small task. Go through your list of open files and write them to the new directory. Start with the unsaved ones. Try to make sure that your crash handler doesn't crash itself
Important: hardcode the location of the save directory, as you should not rely on a possibly corrupted data structure for that one (~/cb-crash-datecode would be the way to go).
Bonus work would be to check on program start, if such a directory exists and provide some options - but simply showing a dialog box with the location of the directory would be fine. Just let the user know, that there may be survivors so he can check.
Worst case: you wrote a huge chunk of unusable data. Not unlike a regular core dump
In short: not rocket science but also not written in a few minutes.
3) What is your problem with autosave?
It litters the filesystem and causes additional work to clean up the backup files. And it is a declaration of bankruptcy: by offering autosave you say, that you can't get your crashes in check and have no other means to preserve user data than to preemptively write it to disk as often as you can. For example, firefox does that - and has gained itself a reputation of wearing out your SSD by writing several gigabytes of preemptive crash recovery data per day. Not an example to follow, I'd say
4) I am also a notorious ctrl+s type and i don't have any problem with it xD
Well, now you are aware of it. Lets see, how you feel in a few weeks about it