runtime: TestEINTR fails on linux/arm64

[zhangfannie]

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

$ go version
go version devel +cb11c981df Tue May 12 19:15:34 2020 +0000 linux/arm64

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="arm64"
GOBIN=""
GOCACHE="/home/fanzha02/.cache/go-build"
GOENV="/home/fanzha02/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/fanzha02/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/fanzha02/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/fanzha02/sharefolder/eclipse/golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/fanzha02/sharefolder/eclipse/golang/pkg/tool/linux_arm64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/fanzha02/work/go_project/gomain/src/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build314668058=/tmp/go-build -gno-record-gcc-switches"

### What did you do? ./all.bash

What did you expect to see?

pass

What did you see instead?

-- FAIL: TestEINTR

[zhangfannie]

I got the trace as following.
crash_test.go:95: testprogcgo EINTR exit status: exit status 2
crash_cgo_test.go:600: want OK
       , got SIGQUIT: quit
        PC=0x465e1c m=0 sigcode=0
        
        goroutine 0 [idle]:
        runtime.futex(0x651028, 0x80, 0x0, 0x0, 0x0, 0xfffffffc, 0xffffc2e9ac68, 0x439644, 0xffffc2e9ac68, 0x4396bc, ...)
        	/home/root/ci-scripts/golang/src/runtime/sys_linux_arm64.s:535 +0x1c
        runtime.futexsleep(0x651028, 0x0, 0xffffffffffffffff)
        	/home/root/ci-scripts/golang/src/runtime/os_linux.go:45 +0x38
        runtime.notesleep(0x651028)
        	/home/root/ci-scripts/golang/src/runtime/lock_futex.go:159 +0x98
        runtime.stopm()
        	/home/root/ci-scripts/golang/src/runtime/proc.go:1885 +0xcc
        runtime.findrunnable(0x4000081000, 0x0)
        	/home/root/ci-scripts/golang/src/runtime/proc.go:2420 +0xa2c
        runtime.schedule()
        	/home/root/ci-scripts/golang/src/runtime/proc.go:2618 +0x294
        runtime.park_m(0x4000302300)
        	/home/root/ci-scripts/golang/src/runtime/proc.go:2786 +0x88
        runtime.mcall(0x650740)
        	/home/root/ci-scripts/golang/src/runtime/asm_arm64.s:172 +0x58
        
        goroutine 1 [semacquire]:
        sync.runtime_Semacquire(0x400001e348)
        	/home/root/ci-scripts/golang/src/runtime/sema.go:56 +0x38
        sync.(*WaitGroup).Wait(0x400001e340)
        	/home/root/ci-scripts/golang/src/sync/waitgroup.go:130 +0x6c
        main.EINTR()
        	/root/ci-scripts/golang/src/runtime/testdata/testprogcgo/eintr.go:73 +0xb0
        main.main()
        	/root/ci-scripts/golang/src/runtime/testdata/testprogcgo/main.go:34 +0x194
        
        goroutine 6 [chan receive]:
        main.EINTR.func1()
        	/root/ci-scripts/golang/src/runtime/testdata/testprogcgo/eintr.go:64 +0x70
        created by main.EINTR
        	/root/ci-scripts/golang/src/runtime/testdata/testprogcgo/eintr.go:63 +0x6c
        
        goroutine 10 [running]:
        	goroutine running on other thread; stack unavailable
        created by main.testNet
        	/root/ci-scripts/golang/src/runtime/testdata/testprogcgo/eintr.go:172 +0xd8
        
        r0      0x651028
        r1      0x80
        r2      0x0
        r3      0x0
        r4      0x0
        r5      0x0
        r6      0x22
        r7      0x0
        r8      0x62
        r9      0x60
        r10     0x0
        r11     0x60
        r12     0x20
        r13     0x0
        r14     0x2ad4a16af668de
        r15     0x2a6bd4f807f8
        r16     0xffffc2e9ac98
        r17     0x464cd4
        r18     0x413
        r19     0x464cd3
        r20     0x4000312720
        r21     0x650ee0
        r22     0x1
        r23     0x0
        r24     0x0
        r25     0x0
        r26     0x5526c0
        r27     0x6353a0
        r28     0x650740
        r29     0xffffc2e9abd8
        lr      0x42fdc8
        sp      0xffffc2e9abe0
        pc      0x465e1c
        fault   0x0

[tklauser]

/cc @ianlancetaylor

[zhangfannie]

The TestEINTR test takes more than 1 minute on my arm64 machine, this test enters runTestProg() function, the runTestProg() will be killed and a stack trace is printed if it does not complete within 1 minute. So we got a SIGQUIT signal and a stack trace. So can we set the run time long?

[bcmills]

The test should complete almost immediately. I wonder if we need to scale the syscall.Kill ticker somehow — it's currently a linear 100μs per tick, which might mean that we interrupt every syscall on slower devices.

Perhaps the signal should be integrated into the spin function instead of run as a persistent background goroutine.

[gopherbot]

Change https://golang.org/cl/233877 mentions this issue: runtime: reduce timing sensitivity in TestEINTR

[bcmills]

@zhangfannie, please try syncing past CL 233877 / commit ee0d40cba454c32876a8730d7029bfa6db073735 and let us know whether that has resolved the problem.

[zhangfannie]

@bcmills Thank you for fix this issue. I have tested it on my machine and it passed. Thank you.

[aclements]

Thanks! I'm closing the issue because the fix was confirmed.

[gopherbot]

Change https://golang.org/cl/234538 mentions this issue: runtime: allocate fewer bytes during TestEINTR