Should application catch "bad" signals such as SIGSEV, SIGBUS?
+3
A:
Only if you have something more meaningful to do than the default action. You can't do very much more than aborting quite rapidly but sometimes trying to save the current work is adequate. But pay attention at not overwriting existing files -- users don't like the replacement of good files even if outdated with garbage.
AProgrammer
2010-03-16 10:21:47
This is good. You might also want to try to write out some form of debugging information too to give the developer a better chance and working out what went wrong.
John Burton
2010-03-16 10:23:46
There are few cases where you need this. E.g. on Linux you can always get a core dump if desired.
Thorsten79
2010-03-16 10:39:54
+6
A:
Those signals are produced in "should never happen" circumstances, when your program is in an undefined state. If you did catch them, continuing execution would be extremely problemeatic, as it would almost certainly cause more, possibly even more severe, errors. Also, if you don't catch them, the OS may be able to do things like produce useful diagnostics such as core dumps. So I would say "no", unless you don't want the core dump, and your error handling does something very simple such as write to a log and terminate.
anon
2010-03-16 10:23:02
Is there some way to catch, handle (e.g. save work) and then re-throw?
Space_C0wb0y
2010-03-16 10:30:24
@Space_Cowboy If you do that, the program will be in a different state, so the core isn't so useful.
anon
2010-03-16 10:33:13
@Space_C0wb0y: Sure, you can catch the signal and raise() it again. But "save work" is difficult in a situation where e.g. your app's file descriptor pool could be overwritten with FFT calculations or a list of grandma's cookie recipe from the database.
Thorsten79
2010-03-16 10:43:12
I certainly understand the point of this. But I also hate programs that crash without at least trying to save my work. If there is a bug in the about box, or parsing someone entrying "x" instead of "2" for number of copies to print then that isn't likely to have corrupted anything and I would at least like it to try to save. You certainly DO need to be very careful though
John Burton
2010-03-16 10:49:58
@JB At the point an app receives a SIGBUS, or whatever, it's to late to save your work. A well written app will have been journaling changes before this happens, which is how recovery mechanisms generally work.
anon
2010-03-16 10:58:26
+1
A:
No you should not. I know it's tempting. But there are only very very few reasons why you would ever want to catch fatal signals such as SIGSEV and SIGBUS.
One of the few exceptions might be to have some extra signalling/postmortem code which tells that your program has failed. Even this should only be done in controlled environments, not in code that ships to hundreds of thousands of users.
You have to be prepared that your postmortem code itself will crash though because SIGSEV and SIGBUS are signs of defective code or data.
Thorsten79
2010-03-16 10:24:00
A:
There can be situation where you must catch signals like SIGSEGV and SIGBUS: one such example is: your pointer points to a mmaped region of memory and you are doing *ptr=x and for example this memory address belongs to a network file and your network is throwing some errors. at this point the only way to do error checking is catch the signal and retry or do something else.
cforfun
2010-03-18 00:29:07