runtime: debug output for fatal signal during signal handling.

[prattmic]

#50936 is a crash due to SIGSEGV while in the SIGPROF signal handler. Since our signal handlers have all signals masked, the SIGSEGV is handled via the default termination action by the kernel, exit via signal 11. This results in no output to stderr at all to aid in debugging.

I think we should try to get a bit more debug info out of such crashes.

One approach may be to unmask some signals during signal handling to detect nested signals. Something like:

func sighandler(...) {
  if getg().m.insig {
    // Also print critical siginfo details: PC, addr
    throw("signal during signal handling")
  }
  
  getg().m.insig = true
  unblocksig(SIGSEGV, SIGBUS, SIGILL, SIGFPE, etc)
  ...

  // Reset insig, mask (does kernel do this?).
}

This approach keeps all signals masked in the sigaction, which limits the risk of infinite signal recursion. The downside being an extra syscall required in the signal handler.

(Edit: What we should do with C signal handlers is unclear. Do we unmask prior to calling a C signal handler? (I'd lean against this)).

cc @aclements @cherrymui @mknyszek

[bcmills]

One approach may be to unmask some signals during signal handling to detect nested signals.

I would worry somewhat about blowing out the signal stack in that case, but I suppose that if we're going to terminate the process either way a dump from a corrupted stack might be preferable to no dump at all.

[aclements]

I would worry somewhat about blowing out the signal stack in that case

We would definitely want to abort hard the moment we get a nested signal. I like @prattmic 's idea of waiting to unblock the signals until after we've checked for a nested signal because it ensures we can't go deeper than two signals.

[bcmills]

What we should do with C signal handlers is unclear. Do we unmask prior to calling a C signal handler?

In general we should call pthread_sigmask or equivalent to make the signal mask match the sa_mask with which the C handler was registered. (We probably do not do that today. If we don't, I consider that a bug.)

[prattmic]

I would worry somewhat about blowing out the signal stack in that case, but I suppose that if we're going to terminate the process either way a dump from a corrupted stack might be preferable to no dump at all.

I worried about this as well, but looking at the (Linux) kernel source, I'm pretty sure that if you are already executing on the sigaltstack then signal delivery does not reset SP to the top of the sigaltstack (it just adds to the bottom of the stack as if sigaltstack is disabled). I'd need to double check this in a real program.

So the stack itself wouldn't get corrupted. Though, if we do a normal throw() with full stack trace [1], I suspect we won't actually include the original signal stack trace in the output without more changes to the traceback code.

[1] I'm not sure this is a great idea, but since signals will be masked, failure should result in immediate termination, so give it a shot I guess?

[ianlancetaylor]

Rolling forward to 1.20. Please comment if you disagree. Thanks.