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.

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

runtime: TestEINTR fails on linux/arm64 #39043

Closed
zhangfannie opened this issue May 13, 2020 · 9 comments
Closed

runtime: TestEINTR fails on linux/arm64 #39043

zhangfannie opened this issue May 13, 2020 · 9 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker Testing An issue that has been verified to require only test changes, not just a test failure. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Go1.15

Comments

@zhangfannie
Copy link
Contributor

zhangfannie commented May 13, 2020 •
edited

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
Copy link
Contributor Author

zhangfannie commented May 13, 2020 •
edited 

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

@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 13, 2020
@ALTree ALTree added this to the Go1.15 milestone May 13, 2020
@tklauser tklauser changed the title runtime: TestEINTR test on arm64. runtime: TestEINTR fails on linux/arm64 May 13, 2020
@tklauser
Copy link
Member

/cc @ianlancetaylor

@zhangfannie
Copy link
Contributor Author

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
Copy link
Contributor

bcmills commented May 13, 2020

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.

@bcmills bcmills added release-blocker Testing An issue that has been verified to require only test changes, not just a test failure. labels May 13, 2020
@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue May 13, 2020
runtime: reduce timing sensitivity in TestEINTR
ee0d40c 
- Don't assume that a process interrupted at 100μs intervals will have
  enough remaining time to make progress. (Stop sending signals
  in between signal storms to allow the process to quiesce.)

- Don't assume that a child process that spins for 1ms will block long
  enough for the parent process to receive signals or make meaningful
  progress. (Instead, have the child block indefinitely, and unblock
  it explicitly after the signal storm.)

For #39043
Updates #22838
Updates #20400

Change-Id: I85cba23498c346a637e6cfe8684ca0c478562a93
Reviewed-on: https://go-review.googlesource.com/c/go/+/233877
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@bcmills
Copy link
Contributor

bcmills commented May 13, 2020

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

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 13, 2020
@zhangfannie
Copy link
Contributor Author

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

@aclements
Copy link
Member

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

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue May 20, 2020
runtime: allocate fewer bytes during TestEINTR
f7f9c8f 
This will hopefully address the occasional "runtime: out of memory"
failures observed on the openbsd-arm-jsing builder:
https://build.golang.org/log/c296d866e5d99ba401b18c1a2ff3e4d480e5238c

Also make the "spin" and "winch" loops concurrent instead of
sequential to cut down the test's running time.

Finally, change Block to coordinate by closing stdin instead of
sending SIGINT. The SIGINT handler wasn't necessarily registered by
the time the signal was sent.

Updates #20400
Updates #39043

Change-Id: Ie12fc75b87e33847dc25a12edb4126db27492da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/234538
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators May 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker Testing An issue that has been verified to require only test changes, not just a test failure. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Go1.15
Development

No branches or pull requests
6 participants
@tklauser @aclements @ALTree @bcmills @gopherbot @zhangfannie