Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: signal handling panics for signals generated by sigqueue/tgkill #26625

aclements opened this issue Jul 26, 2018 · 4 comments

runtime: signal handling panics for signals generated by sigqueue/tgkill #26625

aclements opened this issue Jul 26, 2018 · 4 comments


Copy link

@aclements aclements commented Jul 26, 2018

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)?


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 (

func main() {
	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
	/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.

Copy link

@andybons andybons commented Jul 26, 2018

Hey @aclements when you file bugs in the future can you apply the appropriate labels and milestone to them?

Thank you :)

@andybons andybons added the NeedsFix label Jul 26, 2018
@andybons andybons added this to the Unplanned milestone Jul 26, 2018
Copy link

@ianlancetaylor ianlancetaylor commented Jul 27, 2018

I suppose this ought to be fixed but people who use tgkill on a Go program are confused.

Copy link
Member Author

@aclements aclements commented 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.

Copy link

@bcmills bcmills commented Jul 30, 2018

people who use tgkill on a Go program are confused.

Hey now! 😛
(See #19326.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants