User forums > General (but related to Code::Blocks)

Kind of a feature request (regarding random crashes)

<< < (4/4)

arthur1966:

--- Quote from: BlueHazzard on June 10, 2017, 03:59:32 pm ---1) Best thing to handle crashes is to fix the cause of the crashes.

--- End quote ---

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.


--- Quote from: BlueHazzard on June 10, 2017, 03:59:32 pm ---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...

--- End quote ---

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.


--- Quote from: BlueHazzard on June 10, 2017, 03:59:32 pm ---3) What is your problem with autosave?

--- End quote ---

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 :)


--- Quote from: BlueHazzard on June 10, 2017, 03:59:32 pm ---4) I am also a notorious ctrl+s type and i don't have any problem with it xD

--- End quote ---

Well, now you are aware of it. Lets see, how you feel in a few weeks about it :)

Krice:

--- Quote from: oBFusCATed on June 09, 2017, 10:44:06 pm ---Yes, I've seen visual studio 2015 to crash, now what?
--- End quote ---

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.

oBFusCATed:
Krice: Your argument is half invalid - Codeblocks is written in C++!

sodev:

--- Quote from: oBFusCATed on June 10, 2017, 08:02:22 am ---
--- Quote from: sodev on June 10, 2017, 06:30:24 am ---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.

--- End quote ---
Do you have your own version of the autosave plugin?

--- End quote ---


--- Quote from: sodev on June 10, 2017, 06:30:24 am ---It cant be helped, but i cannot press enter more than three times without pressing CTRL+S in between...

--- End quote ---

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...

--- End quote ---

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.

Krice:

--- Quote from: oBFusCATed on June 14, 2017, 09:47:37 am ---Krice: Your argument is half invalid - Codeblocks is written in C++!
--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page