os, os/exec: *os.Process.Signal panic in MacOS 10.13.3

[ghost]

Please answer these questions before submitting your issue. Thanks!

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

1.9.2 & 1.10

Does this issue reproduce with the latest release?

yes,

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

GOARCH="amd64"
GOBIN="/Users/lpx/work/code/go/bin"
GOCACHE="/Users/lpx/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/lpx/work/code/go"
GORACE=""
GOROOT="/Users/lpx/go"
GOTMPDIR=""
GOTOOLDIR="/Users/lpx/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/sg/2clltlvx0hb2dzb973wrt69h0000gn/T/go-build010749259=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

This code been panic after I upgrade MacOS, but in CentOS it's fine.

go func() {
		for {
			sig := <-sc
			switch sig {
			case syscall.SIGINT:
				//proc.Signal(syscall.SIGINT)
			default:
				proc.Signal(sig)
			}
		}
	}()

What did you expect to see?

Is this a golang bug?

What did you see instead?

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x40886ce]

goroutine 18 [running]:
os.(*Process).signal(0x0, 0x428a880, 0xc420132000, 0x0, 0x0)
        /usr/local/go/src/os/exec_unix.go:56 +0x2e
os.(*Process).Signal(0x0, 0x428a880, 0xc420132000, 0x0, 0x0)
        /usr/local/go/src/os/exec.go:129 +0x3f
main.main.func1(0xc420072240, 0xc42000e058)
        /Users/lpx/work/code/go/src/ku/ku.go:64 +0x80
created by main.main
        /Users/lpx/work/code/go/src/ku/ku.go:56 +0x33d

[tsl0922]

You should give the full runnable reproducing code. If you're using exec.Command, then Command.Process will be nil until process started successfully, thus access to it's member before start may panics.

[odeke-em]

In deed, as @tsl0922 mentioned, please provide a fully runnable and reproducible sample and also please check that Command.Process isn't nil and that Command was started: thank you @tsl0922 for answering this and @lepx for filling the issue.

[ianlancetaylor]

There is nothing we can do without more information.