Description
What version of Go are you using (go version
)?
go version devel +30d7e6449f Mon Jul 23 15:16:01 2018 +0000 linux/amd64
Does this issue reproduce with the latest release?
Yes (Go 1.10). This is reproducible at least to 1.6 and much earlier.
What operating system and processor architecture are you using (go env
)?
linux/amd64
This will apply to all Linux platforms and some BSD platforms (though not Darwin since kill
is the only way to send a signal on Darwin).
What did you do?
package main
import (
"runtime"
"syscall"
)
func main() {
runtime.LockOSThread()
pid := syscall.Getpid()
tid := syscall.Gettid()
syscall.Kill(tid, syscall.Signal(syscall.SIGSEGV))
println("kill ignored")
syscall.Tgkill(pid, tid, syscall.Signal(syscall.SIGSEGV))
println("tgkill ignored")
}
What did you expect to see?
Since these aren't "real" SIGSEGV, I expect the runtime to ignore them (or deliver them to a signal channel if one is registered):
kill ignored
tgkill ignored
What did you see instead?
kill ignored
unexpected fault address 0x2f860002ef35
fatal error: fault
[signal SIGSEGV: segmentation violation code=0xfffffffffffffffa addr=0x2f860002ef35 pc=0x44eb2b]
goroutine 1 [running, locked to thread]:
runtime.throw(0x46d21c, 0x5)
/home/austin/.cache/gover/1.10/src/runtime/panic.go:619 +0x81 fp=0xc42004fe98 sp=0xc42004fe78 pc=0x421f41
runtime.sigpanic()
/home/austin/.cache/gover/1.10/src/runtime/signal_unix.go:395 +0x211 fp=0xc42004fee8 sp=0xc42004fe98 pc=0x433ad1
...
runtime.sighandler
explicitly checks for sigcode SI_USER
in several places to distinguish kernel-generated signals from signals send by the user, but sigcode is only SI_USER
for signals sent specifically by kill
. If the signal was sent by sigqueue
or tkill
/tgkill
(on Linux), sigcode is SI_QUEUE
or SI_TKILL
, respectively.
/cc @ianlancetaylor @bcmills because I know how much they love signals.
Activity
andybons commentedon Jul 26, 2018
Hey @aclements when you file bugs in the future can you apply the appropriate labels and milestone to them?
Thank you :)
ianlancetaylor commentedon Jul 27, 2018
I suppose this ought to be fixed but people who use
tgkill
on a Go program are confused.aclements commentedon Jul 27, 2018
I was using
tgkill
on a Go program, but I probably don't count. :) That's the only reason I stumbled on this. I somewhat doubt this has ever actually affected anyone, but it caused me some eyebrow-raising.I could see people using
sigqueue
on a Go program, though, as a roughly-kill
-equivalent.bcmills commentedon Jul 30, 2018
Hey now! 😛
(See #19326.)