Keep running the program after SIGABRT c++ signal

Question

I use a third library in my c++ program which under certain circumstances emits SIGABRT signal. I know that trying to free non-initialized pointer or something like this can be the cause of this signal. Nevertheless I want to keep running my program after this signal is emitted, to show a message and allow the user to change the settings, in order to cope with this signal.
(I use QT for developing.)

How can I do that?

Answer 1

I use a third library in my c++ program which under certain circumstances emits SIGABRT signal

If you have the source code of that library, you need to correct the bug (and the bug could be in your code).

BTW, probably SIGABRT happens because abort(3) gets indirectly called (perhaps because you violated some conventions or invariants of that library, which might use assert(3) - and indirectly call abort ). I guess that in caffe the various CHECK* macros could indirectly call abort . I leave you to investigate that.

If you don't have the source code or don't have the capacity or time to fix that bug in that third party library, you should give up using that library and use something else.

In many cases, you should trust external libraries more than your own code. Probably, you are abusing or misusing that library. Read carefully its documentation and be sure that your own code calling it is using that library correctly and respects its invariants and conventions. Probably the bug is in your own code , at some other place.

I want to keep running my program

This is impossible (or very unreliable, so unreasonable). I guess that your program has some undefined behavior . Be very scared , and work hard to avoid UB.

You need to improve your debugging skills. Learn better how to use the gdb debugger , valgrind , GCC sanitizers (eg instrumentation options like -fsanitize=address , -fsanitize=undefined and others), etc...

You reasonably should not try to handle SIGABRT even if in principle you might (but then read carefully signal(7) , signal-safety(7) and hints about handling Unix signals in Qt ). I strongly recommend to avoid even trying catching SIGABRT .

Answer 2

Unfortunately, you can't . SIGABRT signal is itself sent right after abort()

Ref: https://stackoverflow.com/a/3413215/9332965

Answer 3

You can handle SIGABRT , but you probably shouldn't .

---

The "can" is straightforward - just trap it in the usual way, using signal() . You don't want to return from this signal handler - you probably got here from abort() - possibly originally from assert() - and that function will exit after raising the signal. You could however longjmp() back to a state you set up earlier.

---

The "shouldn't" is because once SIGABRT has been raised, your data structures (including those of Qt and any other libraries) are likely in an inconsistent state and actually using any of your program's state is likely to be unpredictable at best. Apart from exiting immediately, there's not much you can do other than exec() a replacement program to take over in a sane initial state.

If you just want to show a friendly message, then you perhaps could exec() a small program to do that (or just use xmessage ), but beware of exiting this with a success status where you would have had an indication of the SIGABRT otherwise.

Answer 4

Unfortunately there isn't much you can do to prevent SIGABRT from terminating your program. Not without modifying some code that was hopefully written by you.

You would either need to change code to not throw an abort, or you would have to spawn a new process that runs the code instead of the current process. I do not suggest you use a child process to solve this problem. It's most likely caused by misuse of an api or computer resources, such as low memory.