2

I have an application which starts multiple threads. I am using a signal handler to catch the signals.

I don't want my application to quit on SIGSEGV; I want to terminate only the thread that incurred the signal, and to continue the flow of the full application in the other threads. Is it possible?

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
Vivek Goel
  • 22,942
  • 29
  • 114
  • 186
  • @asveikau it is server application and I will be sending alert on SIGGEV but I don't want to affect other threads due to crash in one thread. Is it not same as exception handling in c++ ? – Vivek Goel Sep 03 '11 at 05:10
  • 4
    If you want isolation from crashes use multiple processes, not threads. If the faulting code lives in the same address space as the rest of your server, it will very likely leave the rest of your process in a bad state. Not to mention you should write your server such that it doesn't crash in the first place..... – asveikau Sep 03 '11 at 05:13
  • any reason for down vote ? I came to know that , it is bad approach. But should I not clear my doubt on this site ? – Vivek Goel Sep 03 '11 at 05:22
  • No, it's not the same as exception handling in C++. Look here for a discussion of pthread_sigmask (): http://www.linuxjournal.com/article/2121 – paulsm4 Sep 03 '11 at 05:27
  • What is `SIGGEV`? Do you mean `SIGSEGV`? – Keith Thompson Sep 03 '11 at 05:30
  • 1. I'm pretty sure a SIGSEV will not be caught in a try {} catch(){}. 2. Your program needs to end on a SIGSEV, period. Ever heard of the Blue Screen of death? That's what happens when bad pointers run amok. Also, this falls outside of the purpose of exception handling. Exception handling is for errors generated by users and outside influences, not for catching programming errors. SIGSEV is always a programming error. – Jonathan Henson Sep 03 '11 at 05:55

1 Answers1

5

If a SIGSEGV happens, it indicates that your program has already invoked undefined behavior, i.e. the state of the entire program is undefined/indeterminate/invalid. In practice it's possible that you may be able to recover and keep running, but there's no guarantee, and it could be dangerous.

As asveikau mentioned, you could longjmp out of the signal handler and try to clean up, but this could make an even worse mess if the crash happened in the middle of malloc, free, printf, or any function modifying the state of global data or data that's shared with other threads or that will be accessed in the cleanup code at the longjmp destination. The state may be corrupt/inconsistent, and/or locks may be held and left permanently unreleasable.

If you can ensure this won't happen - for example if the misbehaving thread never calls any async-signal-unsafe functions - then it may be safe to longjmp out of the signal handler then call pthread_exit.

An alternative might be to permanently freeze the thread in the signal handler, by adding all signals to the sa_mask for SIGSEGV and then writing for (;;) pause(); in the signal handler. This is 100% "safe", but may leave the process in a deadlocked state if any locks were held by the crashing thread. This is perhaps "less bad" than exposing corrupt state to other threads and further clobbering your data to hell...

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • I did mention `longjmp` in my initial comment, but I removed that suggestion.. Bad idea or not, it likely is not what he's asking about and probably would cause more confusion than he started with. – asveikau Sep 03 '11 at 06:23