Go version
go version go1.22.1 darwin/arm64
Output of go env in your module/workspace:
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/spike/Library/Caches/go-build'
GOENV='/Users/spike/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/spike/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/spike/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.1'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/53/zffdtv3x7lg_pyhrk85p7_nw0000gn/T/go-build3395173330=/tmp/go-build -gno-record-gcc-switches -fno-common'
What did you do?
I have noticed this behavior since upgrading to macOS 14.4. I don't believe it was present in macOS 14.2
If I have a test case that starts a process and then sends a SIGINT to it, the signal is not delivered if the test case is run via test2json. If it is run directly via go test or by directly executing a test binary, the signal is delivered.
The following is a minimal testcase that reproduces the behavior:
package execsigs
import (
"errors"
"os"
"os/exec"
"testing"
)
func TestSigInt(t *testing.T) {
cmd := exec.Command("sleep", "10")
err := cmd.Start()
if err != nil {
t.Fatal(err.Error())
}
err = cmd.Process.Signal(os.Interrupt)
if err != nil {
t.Fatal(err.Error())
}
err = cmd.Wait()
var exitErr *exec.ExitError
if !errors.As(err, &exitErr) {
t.Fail()
}
}
What did you see happen?
If I run this test via go test or create a binary and run it, it passes:
spike@Codebook execsigs % go test -v execsigs_test.go
=== RUN TestSigInt
--- PASS: TestSigInt (0.00s)
PASS
ok command-line-arguments 0.833s
spike@Codebook execsigs % go test -c -o test execsigs_test.go
spike@Codebook execsigs % ./test -test.v
=== RUN TestSigInt
--- PASS: TestSigInt (0.00s)
PASS
But if I run via test2json, it fails. The SIGINT is not delivered to sleep and so instead of exiting with an error, the test takes 10 seconds and the process exits cleanly.
spike@Codebook execsigs % go tool test2json ./test -test.v=test2json
{"Action":"start"}
{"Action":"run","Test":"TestSigInt"}
{"Action":"output","Test":"TestSigInt","Output":"=== RUN TestSigInt\n"}
{"Action":"output","Test":"TestSigInt","Output":"--- FAIL: TestSigInt (10.01s)\n"}
{"Action":"fail","Test":"TestSigInt"}
{"Action":"output","Output":"FAIL\n"}
{"Action":"fail"}
What did you expect to see?
test2json result of the test should be identical to go test, i.e. the SIGINT is delivered to the process during the test.
This is pretty annoying because IDEs like GoLand depend on test2json to execute go tests under the hood.
Go version
go version go1.22.1 darwin/arm64
Output of
go envin your module/workspace:What did you do?
I have noticed this behavior since upgrading to macOS 14.4. I don't believe it was present in macOS 14.2
If I have a test case that starts a process and then sends a
SIGINTto it, the signal is not delivered if the test case is run via test2json. If it is run directly viago testor by directly executing a test binary, the signal is delivered.The following is a minimal testcase that reproduces the behavior:
What did you see happen?
If I run this test via
go testor create a binary and run it, it passes:But if I run via
test2json, it fails. The SIGINT is not delivered tosleepand so instead of exiting with an error, the test takes 10 seconds and the process exits cleanly.What did you expect to see?
test2jsonresult of the test should be identical togo test, i.e. the SIGINT is delivered to the process during the test.This is pretty annoying because IDEs like GoLand depend on
test2jsonto execute go tests under the hood.