/cc @ianlancetaylor

The link to the documentation didn't work for me, so here is an update link for whomever investigates this: https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG

I don't see what we can do here. The Go signal handler has to do something. It sounds like what it does here doesn't work with your C program, but it still seems like the best chance of working with a typical program. Why does your C signal handler re-raise SIGSEGV?

Why does your C signal handler re-raise SIGSEGV?

At some case, I want the C signal handler to just dump stack trace when segfault, then re-raise the signal to system default handler.

But presumably when you re-raise the signal you first remove the C signal handler, which ought to mean that you get the default handler and crash the program. How does the Go signal handler come back?

But presumably when you re-raise the signal you first remove the C signal handler, which ought to mean that you get the default handler and crash the program.

That's exactly what I want to do with specifying sigaction.sa_flags with SA_RESETHAND.

sa_flags specifies a set of flags which modify the behavior of the signal.  It is formed by 
the bitwise OR of zero or more of the following:

SA_RESETHAND
    Restore the signal action to the default upon entry to the signal handler.

How does the Go signal handler come back?

Following the startup code (_rt0_amd64_lib), I believe the synchronous signals handler is changed to the Go signal handler cgoSigtramp, and the previous C signal handler is stored at fwdSig.

As above, the Go signal handler is the current signal handler, it will tramp the synchronous signal and if the signal occurred not in Go code, it will forward the signal to the system or the C handler, in this case is the C handler. Then C handler it this case has re-raised the same signal. When Go signal handler tramped the signal, this process will repeate again.

The sigfwdgo has not checked the established sa_flags of the C handler, as a result SA_RESETHAND is ignored.

I believe if sigfwdgo can find a way to check the sa_flags of the C handler, if sa_flags & SA_RESETHNAD is true, reset fwdSig[signo] to _SIG_IGN, then the next time when the same synchronized signal get tramped, the C signal handler will not get forward. But I haven't see where the sa_flags is recorded.

func sigfwdgo(sig uint32, info *siginfo, ctx unsafe.Pointer) bool {
	if sig >= uint32(len(sigtable)) {
		return false
	}
	fwdFn := atomic.Loaduintptr(&fwdSig[sig])
	flags := sigtable[sig].flags

	// If there is no handler to forward to, no need to forward.
	if fwdFn == _SIG_DFL {
		return false
	}

	c := &sigctxt{info, ctx}
	// Only forward synchronous signals and SIGPIPE.
	// Unfortunately, user generated SIGPIPEs will also be forwarded, because si_code
	// is set to _SI_USER even for a SIGPIPE raised from a write to a closed socket
	// or pipe.
	if (c.sigcode() == _SI_USER || flags&_SigPanic == 0) && sig != _SIGPIPE {
		return false
	}
	// Determine if the signal occurred inside Go code. We test that:
	//   (1) we were in a goroutine (i.e., m.curg != nil), and
	//   (2) we weren't in CGO.
	g := getg()
	if g != nil && g.m != nil && g.m.curg != nil && !g.m.incgo {
		return false
	}

	// Signal not handled by Go, forward it.
	// forward to system or the C handler
	if fwdFn != _SIG_IGN {
		sigfwd(fwdFn, sig, info, ctx)
	}

	return true
}

Thanks, that seems reasonable.

I don't think this is limited to just SA_RESETHAND. In general, when forwarding a signal the handler should:

• Fix up the signal mask to match the sa_mask of the next handler, adding or removing the current signal in the mask depending on whether SA_NODEFER is set in the sa_flags of the next handler.
• If SA_RESETHAND is set in the sa_flags of the next handler, update the signal-forwarding state to avoid forwarding any future signals.
• If SA_NOCLDSTOP is set in the sa_flags of the next handler and the signal is SIGCHLD, filter out "stop" and "continue" events.
• Clean up any allocated or locked state. (The next handler in the chain may or may not return.)
• Finally, call the handler, including the siginfo_t and context parameters if SA_SIGINFO is set in its sa_flags.

I don't think the Go runtime is currently doing any of those three preliminary steps.