cmd/vet, os/signal: possible false-positive in sigchanyzer check when os.Signal channel is unused

[dmitshur]

What version of Go are you using (go version)?

$ gotip version
go version devel +8ed438c07 Mon Mar 15 20:48:37 2021 +0000 darwin/amd64

Does this issue reproduce with the latest release?

No.

What operating system and processor architecture are you using (go env)?

go env Output

$ gotip env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dmitshur/Library/Caches/go-build"
GOENV="/Users/dmitshur/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dmitshur/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/dmitshur/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/dmitshur/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/dmitshur/sdk/gotip/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel +8ed438c07 Mon Mar 15 20:48:37 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/tmp.YEX3UfOo/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zb/5p8cwfhj29gf_m8vdy8ylmlr00jwcj/T/go-build3265915026=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I wrote a program that appears to be correct. It uses signal.Notify to catch SIGINT signals to prevent default handling but otherwise completely ignore them:

package main

import (
	"os"
	"os/signal"
	"time"
)

func main() {
	signal.Notify(make(chan os.Signal), os.Interrupt) // ignore SIGINT
	time.Sleep(10 * time.Second)
}

Then ran gotip vet . on it.

What did you expect to see?

No vet report, because as far as I can tell the os.Signal channel doesn't need to be buffered when it's completely unused.

What did you see instead?

$ gotip vet .
# m.test
./main.go:10:2: misuse of unbuffered os.Signal channel as argument to signal.Notify

CC @odeke-em, @ianlancetaylor, @timothy-king.

[timothy-king]

I am not sure I understand why this is safe yet. (So no informed cmd/vet opinion yet.)

[zikaeroh]

This came up in CL 217765 for #36976, where I copied a function from cmd/go/internal/base to the dl wrapper to make sure the parent process doesn't also spit out traces. But, cmd/go needs to actually use the signal to make a note that it was interrupted. dl doesn't, so doesn't actually care whether or not it can observe the signal (it's just going to exit once the child is gone anyway).

[ianlancetaylor]

Code like signal.Notify(make(chan os.Signal), os.Interrupt) is safe because the runtime always writes to the channel using a non-blocking send. This is in effect a way to ignore the signal. (It would be better to use signal.Ignore, but that is a separate issue.)

It's not safe to write code like

    c := make(chan os.Signal)
    signal.Notify(c, os.Interrupt)
    // use c somewhere

because the fact that the runtime uses a non-blocking send means that if the channel is unbuffered signals can be lost. In the case where the make is invoked directly in the call to signal.Notify, nothing is ever going to read from the channel, so the fact that signals can be lost is unimportant.

[odeke-em]

Roger that, thanks everyone for the discussion. I shall send a change tomorrow morning/afternoon, and get this fixed.

[zikaeroh]

Thanks for the pointer to signal.Ignore, I didn't remember that there was a distinct function for this. (I don't think I can use it in my CL anyway, given I assume golang.org/dl probably still needs to support Go 1.4. Oh well.)

[AGMETEOR]

@odeke-em , I would like to fix this in the sigchanyzer

[odeke-em]

All yours, thank you @AGMETEOR and welcome to the Go project, great to have you become a contributor!

[ianlancetaylor]

Is the pull request for this going to get in for 1.17? Thanks.

[odeke-em]

It is! Just got stalled. @cuonglm, let’s take over, @AG-Meteor we can select another bug later on, thanks for the contributions and offline we can work on something else :-)

…

On Mon, Apr 19, 2021 at 4:00 PM Ian Lance Taylor ***@***.***> wrote: Is the pull request for this going to get in for 1.17? Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45043 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABFL3V34M3M74RVMIEMF3IDTJSYZ3ANCNFSM4ZHJ6TCA> .

[AGMETEOR]

I am implementing @cuonglm feedback now. If by EOD I haven't finished then he can take over
Update: @odeke-em I have made some changes to the PR. Hopefully @cuonglm has some time to take a look asap.

[gopherbot]

Change https://golang.org/cl/311729 mentions this issue: passes/sigchanyzer: allow valid inlined unbuffered signal channel

[gopherbot]

Change https://golang.org/cl/312631 mentions this issue: cmd/vendor: get golang.org/x/tools@f946a157eef

[wnz27]

I can't understant upgrade golanglint but it still: sigchanyzer: misuse of unbuffered os.Signal channel as argument to signal.Notify

[ianlancetaylor]

@wnz27 This issue is closed and we believe that it is fixed. If you have a case where the warning is being issued inappropriately, please open a new issue with instructions for how to reproduce the problem. If you are asking a question, please see https://golang.org/wiki/Questions. Thanks.

[wnz27]

@wnz27 This issue is closed and we believe that it is fixed. If you have a case where the warning is being issued inappropriately, please open a new issue with instructions for how to reproduce the problem. If you are asking a question, please see https://golang.org/wiki/Questions. Thanks.

thanks， i feel sorry for that