Printable View
Hi,
I am struggling with GUI exit when a unix signal occurs, such as SIGSEGV or assert( false ). What I hope is to catch this signal and keep the application alive in order to give users a chance to save his data instead of losing everything in the middle of a job.
I am trying to write this signal handler, but it doesn't work as the signal occurs in the middle of the Qt event loop.
Please someone have a look at my codes and see if you can help.
Thanks.
Intercepting SIGSEGV is very tricky and in general you shouldn't do that. And even if you do, you musn't call any Qt (or GUI in general) routines unless you are sure it is safe. Without knowing what causes the segmentation fault you are trying to force the application to continue if its stack or instruction pointer is corrupted which simply won't make sense. If you want to install a signal handler for SIGSEGV, do it only temporarily and only in places you expect specific things to happen (i.e. you protected some area of memory with mprotect() and you expect a call might try to violate this protection). If segmentation fault occurs within Qt event loop, it is probably left unusable so you won't be able to enter it again hence no GUI calls will make sense. You might try some automatic emergency backup creation using low-level routines (like iostream) but don't overwrite existing files as the backup mail fail as well.
I agree. But sometime the error may come from user inputs, and it is hard to catch all the errors that users may enter from the GUI.Quote:
Originally Posted by wysota
For instance, I want to allocate an array
float* array = new float[ size ]
where the "size" comes from user input. If user input "-1", it may crash. Of course inside the program we should check the user input value. But let's say you forget to check, and hope to catch the signal, then notify user something is wrong, he will then realize the problem and re-enter the value.
Simply crash the application is not a nice way in handling such error. It is much nicer to allow user a chance to save the data so he/she doesn't lose what has been done so far.
I have seen such signal intercepting before. But I don't know how to implement it. The GUI never disappears unless you click "Exit" or "kill -9". It gives error message to allow users choose other approaches.
Last years, we evaluated several vendor applications, there were several applications crashed (GUI disappearing) in the middle of evaluation tests. The testers immediately throw it to junk list...It really makes a big difference...
Everything that comes from user input may be validated.Quote:
Originally Posted by lni
It's easy to check that. Especially that you should get an exception you can catch.Quote:
For instance, I want to allocate an array
float* array = new float[ size ]
where the "size" comes from user input. If user input "-1", it may crash.
Well then don't forget it :)Quote:
But let's say you forget to check,
Of course this is my personal opinion but applications crashes (let's call intercepting a SIGSEGV a crash as well) are caused by developers, not end-users.Quote:
Simply crash the application is not a nice way in handling such error. It is much nicer to allow user a chance to save the data so he/she doesn't lose what has been done so far.
It all depends where the crash occurs. Qt is a high level framework. It's not safe to bail out of any method in any place possible. I'm sure if you corrupted the instruction pointer, the solution you mention wouldn't have worked. And it's easy to corrupt the instruction pointer by overwriting the stack frame through buffer overruns for example.Quote:
I have seen such signal intercepting before. But I don't know how to implement it. The GUI never disappears unless you click "Exit" or "kill -9". It gives error message to allow users choose other approaches.
I'd do the same regardless if they showed me a crash handler dialog or not. If an application crashes, it is badly written. If it crashes and shows a crash handler dialog it is also badly written and the only difference is that developers instead of fixing the bugs in question try to hide them or reduce damage made by them using the mentioned handlers. But the bugs are still there.Quote:
Last years, we evaluated several vendor applications, there were several applications crashed (GUI disappearing) in the middle of evaluation tests. The testers immediately throw it to junk list...It really makes a big difference...
as far as i know, the best way to catch the unwanted behavior is to run application under debugger and check for all bugs :] Testing is more important, more expensive and more time consuming than writing code. The better the application is designed, the better is written, the less bugs are in the first compilable version. So my advice is to not catch SIGSEGV but to fix the bug which causes the SIGSEGV.
P.S. Fixing bugs in testing phase can be even 100 more expensive and time consuming than fixing those bugs in design phase :]
I completely agree what you two are saying. I also understand that any crash is due to bad codes, and it is the developers that need to be blamed.
Unfortunately, no software is bug free. So what I am hoping is that in the event there is an uncaught bug, the GUI application should give a best effort to provide a nicer way of ending the application...
Having said that, I hope someone can find a solution to the problem...
You can spawn a separate application as a crash handler. But I advise against continuing the original application.