1

I cannot understand behavior of the program when it blocks hardware generated signals such as SIGSEGV and then gets this signal. For example, if there are a signal handler for SIGSEGV which was installed with sigaction (signal is blocked inside the handler) but the program gets another SIGSEGV inside the handler. I cannot find the description of how the program should behave in this case. As I understand, on Linux the signal will unblock and program will crash. But what about other Unix systems, is it specified somewhere?

Thank you.

Henrik Sachse
  • 51,228
  • 7
  • 46
  • 59
fadsend
  • 35
  • 1
  • 5
  • When a `SIGSEGV` is raised and the handler returns, the same instruction is restarted (in this case same one that caused `SIGSEGV`) and your handler is going to called again -- leading to infinite loop. If your program receives `SIGSEGV` there's a high probability that there's UB. So you should fix that rather trying to handle `SIGSEGV`. – P.P Aug 09 '15 at 19:29

1 Answers1

2

Most if not all synchronous generation of SIGSEGV is a result of undefined behavior, and therefore it's not meaningful to ask what happens; the result is explicitly left undefined. Blocking SIGSEGV is only meaningful when the signal is being sent via kill, sigqueue, pthread_kill, etc.

My experience in practice is that UB that causes SIGSEGV causes the program to terminate, as if by an untrapped SIGSEGV, if SIGSEGV is blocked. But since it's UB it's possible that no trap happens at all, or that the compiler completely reorders the code in unexpected ways or optimizes out the whole program. Don't rely on any of this.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 1
    This answer is conflating different abstraction layers. UB is a property of your programming language. SIGSEGV is an MMU (virtual memory hardware) exception. SIGSEGV does _not_ necessarily imply that any UB occurred, it only means you tried to access memory that isn't mapped. The reason you can't block it is because after the signal is raised the program retries the same operation that caused the problem. Your signal handler must fix the problem by mapping the memory or changing the pointer to something valid, otherwise the program goes into an infinite loop. – Kenton Varda Feb 10 '16 at 21:08