-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Description
What version of Go are you using (go version
)?
$ go version go version devel go1.19-2aa473cc54 Fri Jul 15 14:56:54 2022 +0000 linux/s390x
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="s390x" GOBIN="" GOCACHE="/home/jalbrecht/.cache/go-build" GOENV="/home/jalbrecht/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="s390x" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/jalbrecht/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/jalbrecht/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/jalbrecht/src/goroot" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/jalbrecht/src/goroot/pkg/tool/linux_s390x" GOVCS="" GOVERSION="devel go1.19-2aa473cc54 Fri Jul 15 14:56:54 2022 +0000" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/jalbrecht/src/goroot/src/go.mod" GOWORK="" 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 -march=z196 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build182921307=/tmp/go-build -gno-record-gcc-switches"
What did you do?
cd misc/cgo/testcarchive
go test -failfast -count=5000 -timeout=0 -run TestSignalForwardingExternal
What did you expect to see?
Test should always pass
What did you see instead?
--- FAIL: TestSignalForwardingExternal (1.85s)
carchive_test.go:681: got signal: quit (core dumped); expected signal segmentation fault
FAIL
exit status 1
FAIL misc/cgo/testcarchive 5177.741s
This test failed twice while I was testing new s390x builder hardware:
https://build.golang.org/log/b7171701f23a01295fc598a1ea596f5b1e2431e5
https://build.golang.org/log/2a0f9a0cade96e1972aed5ed315721f82c3031b0
This failure could also happen on other architectures but for some reason its more likely to happen on the new machine I'm testing. As far as I'm able to see, this failure has not happened on the existing s390x builders.
I'm able to reproduce the same failure on linux amd64 by removing the code related to waiting for the testp
program to send the OK
trigger which makes the window where a go thread could handle the SIGSEV signal larger:
go/misc/cgo/testcarchive/carchive_test.go
Line 630 in 2aa473c
ok, err := r.ReadString('\n') |
I ran the test under strace and I think this could happen since this CL in go1.15 which makes SIGSEGV always crash the go program. In c-archive programs GOTRACEBACK=crash is always effectively set and that causes the go signal handler to send SIGINT to its own process:
Line 788 in 2aa473c
raiseproc(_SIGQUIT) |
and that's how the tests sees the
testp
process has exited with SIGINT instead of SIGSEGV.
I think the fix could be for the test to send SIGUSR1 to testp
instead of SIGSEGV. I've tried that out on s390x and amd64 and haven't seen any failures. If that makes sense, I can submit a CL.