Skip to content

misc/cgo: TestSignalForwardingExternal sometimes fails with wrong signal SIGINT #53907

@jonathan-albrecht-ibm

Description

@jonathan-albrecht-ibm

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:

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:

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions