0

The following comment in breakpad suggests that resetting the signal handler forces the signal to be rethrown. However, I wasn't able to find any documentation online that describes this behaviour.

Additionally, the comment here says once the signal handler returns, the signal will be rethrown. Is this also as a result of the signal handler being restored or reset to the default?

black
  • 781
  • 1
  • 7
  • 22

1 Answers1

0

suggests that resetting the signal handler forces the signal to be rethrown

says once the signal handler returns, the signal will be rethrown

Neither is true. However, I don't believe that's what the comments imply. The likely case is that it leaves the signal unprocessed in some cases. So the original problem that triggered the signal triggers the same signal again. Consider this example:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>

void handler(int sig)
{
    write(1, "Received FPE\n", sizeof "Received FPE\n" - 1);
}

int  main(void)
{
    signal(SIGFPE, handler);
    printf("%f", 1/0);
}

(This should cause an infinite loop).

SIGFPE isn't really "handled" here. So the once the control returns back from the signal handler, SIGPFE is repeatedly triggered. I believe this is scenario that's referred to in those comments.

Similarly, when signals are blocked they'll be queued and sent to the process once they're unblocked. They are masking it when installing their signal handler. This is likely what the second comment refers to. Masking can also be done via sigprocmask or pthread_sigmask.

Community
  • 1
  • 1
P.P
  • 117,907
  • 20
  • 175
  • 238
  • So without explicitly exiting or restoring the default handler, a signal will be continuously delivered? Also a related question: any idea why breakpad doesn't always restore the previous handler, and instead chooses based on the `handled` result? – black Nov 14 '19 at 13:53
  • "So without explicitly exiting or restoring the default handler, a signal will be continuously delivered?" - yes, for certain (not for all) signals like FPE, SIGV, etc. I am not familiar with breakpad's logic/implementation (never heard of it before today :). I'd think it's more natural to restore the "previous handler" that the application might have installed. – P.P Nov 14 '19 at 14:07
  • Looks like breakpad offers a choice of propagating the exception to a previously set handler during pre and post processing of the signal. Hence the option to restore or set a default handler. – black Nov 15 '19 at 11:25