You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
runtime.dieFromSignal is called in a few places in the runtime where we've handled a fatal signal and intend to terminate the process.
At the moment, dieFromSignal unconditionally calls setsig(sig, _SIG_DFL) and re-raises the signal.
That's pretty much always the right thing to do in a pure-Go program.
However, in a mixed-language program there may be some existing signal handler, and that signal handler might want to do something useful — for example, save a core dump, mark an input record as a potential cause of the crash, or write an entry to a crash log.
It seems to me that we could address this use-case pretty easily by making dieFromSignal try to reinstall and raise to the previous handler before it resorts to SIG_DFL. Perhaps something like:
funcdieFromSignal(siguint32) {
fwdFn:=atomic.Loaduintptr(&fwdSig[sig])
iffwdFn!=_SIG_DFL {
setsig(sig, fwdFn)
unblocksig(sig)
raise(sig)
}
// fwdSig[sig] either didn't exist or failed to terminate the process.// Try _SIG_DFL instead.setsig(sig, _SIG_DFL)
unblocksig(sig)
raise(sig)
// That should have killed us. On some systems, though, raise// sends the signal to the whole process rather than to just// the current thread, which means that the signal may not yet// have been delivered. Give other threads a chance to run and// pick up the signal.osyield()
osyield()
osyield()
// If we are still somehow running, just exit with the wrong status.exit(2)
}
In the typical case — when there are no handlers registered before ours — the behavior would be the same as it is today. On the off chance that some other language has registered a prior handler, we would instead invoke that handler, and if it isn't well behaved (i.e. doesn't terminate the process), then we fall back to today's behavior anyway.
The text was updated successfully, but these errors were encountered:
The dieFromSignal runtime function attempts to forward crashing
signals to a signal handler registered before the runtime was
initialized, if any. However, on Darwin, a special signal handler
trampoline is invoked, even for non-Go signal handlers.
Clear the crashing signal's handlingSig entry to ensure sigtramp
forwards the signal.
Fixes the darwin/386 builder.
Updates #20392
Updates #19389
Change-Id: I441a3d30c672cdb21ed6d8f1e1322d7c0e5b9669
Reviewed-on: https://go-review.googlesource.com/55032
Run-TryBot: Elias Naur <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
runtime.dieFromSignal
is called in a few places in the runtime where we've handled a fatal signal and intend to terminate the process.At the moment,
dieFromSignal
unconditionally callssetsig(sig, _SIG_DFL)
and re-raises the signal.That's pretty much always the right thing to do in a pure-Go program.
However, in a mixed-language program there may be some existing signal handler, and that signal handler might want to do something useful — for example, save a core dump, mark an input record as a potential cause of the crash, or write an entry to a crash log.
It seems to me that we could address this use-case pretty easily by making
dieFromSignal
try to reinstall and raise to the previous handler before it resorts toSIG_DFL
. Perhaps something like:In the typical case — when there are no handlers registered before ours — the behavior would be the same as it is today. On the off chance that some other language has registered a prior handler, we would instead invoke that handler, and if it isn't well behaved (i.e. doesn't terminate the process), then we fall back to today's behavior anyway.
The text was updated successfully, but these errors were encountered: