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.

Sign up for GitHub

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

Jump to bottom

cmd/test2json: tests inherit signal.Ignore from test2son #66556

Open
spikecurtis opened this issue Mar 27, 2024 · 3 comments
Open

cmd/test2json: tests inherit signal.Ignore from test2son #66556

spikecurtis opened this issue Mar 27, 2024 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

Comments

@spikecurtis
Copy link

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.
@seankhliao
Copy link
Member

Duplicate of #54023

@seankhliao seankhliao marked this as a duplicate of #54023 Mar 27, 2024
@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2024
@spikecurtis
Copy link
Author

This is NOT a duplicate of #54023 which appears to be about whether test2json handles signals sent to it. This is about whether a unit test can successfully send a signal to a 3rd process created by the test.

@seankhliao seankhliao changed the title cmd/test2json: signals are not sent to os.Process when run via test2json cmd/test2json: tests inherit signal.Ignore from test2son Mar 27, 2024
@seankhliao
Copy link
Member

Right, i see now.
I think this comes from CL 419295 for #53563

@seankhliao seankhliao reopened this Mar 27, 2024
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@spikecurtis @seankhliao