Author Topic: Kind of a feature request (regarding random crashes)  (Read 1742 times)

Offline arthur1966

  • Single posting newcomer
  • *
  • Posts: 7
Re: Kind of a feature request (regarding random crashes)
« Reply #15 on: June 10, 2017, 06:21:18 pm »
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 :)

Offline Krice

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Kind of a feature request (regarding random crashes)
« Reply #16 on: June 14, 2017, 09:25:38 am »
Yes, I've seen visual studio 2015 to crash, now what?

I think it has crashed once as far as I remember. That's not very often. I recall C::B is written in C so catching exceptions ("soft" crashes) is not meaningful. And with hard crash you can't do anything. This means the feature request can't be done. My personal opinion about C is that it's sad that large scale projects are still today written in C and sometimes without any kind of protection methods (for arrays etc.). It doesn't make a lot of sense, because the developers are making it 1000% harder for themselves than it should be.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10398
Re: Kind of a feature request (regarding random crashes)
« Reply #17 on: June 14, 2017, 09:47:37 am »
Krice: Your argument is half invalid - Codeblocks is written in C++!
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline sodev

  • Multiple posting newcomer
  • *
  • Posts: 108
Re: Kind of a feature request (regarding random crashes)
« Reply #18 on: June 14, 2017, 07:08:05 pm »
So i see no problem here as well. However i prefer my own integrated AutoSave, so far i have lost almost nothing (and when i lost something it was usually because of my AutoSave keeping only one copy :) ) in all these years of using CodeBlocks.
Do you have your own version of the autosave plugin?

It cant be helped, but i cannot press enter more than three times without pressing CTRL+S in between...

Im sorry to disappoint you, but that is my "autosave plugin" ;).

Quote
Please report them in another topic or on the sf.net tickets page. Make sure you're using a night build. There are tons of problems fixed in wx3 builds...

Strange, i tought i made a newer post about this, but apparently i have only this http://forums.codeblocks.org/index.php/topic,19758.msg134929.html#msg134929 which evolved to this http://forums.codeblocks.org/index.php/topic,21710.msg148158.html#msg148158. I'm not using any nightlies, i always compile myself from svn.

Offline Krice

  • Multiple posting newcomer
  • *
  • Posts: 56
Re: Kind of a feature request (regarding random crashes)
« Reply #19 on: June 15, 2017, 09:15:24 am »
Krice: Your argument is half invalid - Codeblocks is written in C++!

Maybe, but it can still be C-style. I guess I could look at the source code to be sure.

Yes, there is some C style stuff. But that's not the worst thing. Checking out the source with CppCheck shows a lot of problems that could be easily fixed. Trust me guys, you want to use CppCheck to improve the quality of the source code.
« Last Edit: June 15, 2017, 09:56:48 am by Krice »