Skip to content

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

Open
@aclements

Description

@aclements

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

andybons commented on Jul 26, 2018

@andybons
Member

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

Thank you :)

added
NeedsFixThe path to resolution is known, but the work has not been done.
on Jul 26, 2018
added this to the Unplanned milestone on Jul 26, 2018
ianlancetaylor

ianlancetaylor commented on Jul 27, 2018

@ianlancetaylor
Contributor

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

aclements

aclements commented on Jul 27, 2018

@aclements
MemberAuthor

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

bcmills commented on Jul 30, 2018

@bcmills
Contributor

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    NeedsFixThe path to resolution is known, but the work has not been done.compiler/runtimeIssues related to the Go compiler and/or runtime.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @andybons@aclements@ianlancetaylor@bcmills@gopherbot

        Issue actions

          runtime: signal handling panics for signals generated by sigqueue/tgkill · Issue #26625 · golang/go