go: syscall: Setgroups may hang in go 1.16+ when not using cgo
What version of Go are you using (go version
)?
$ go version go version go1.16 linux/amd64
Does this issue reproduce with the latest release?
Yes, this problem will also exist in go 1.17.5, but not exist in go 1.15.x.
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/demo/.cache/go-build" GOENV="/home/demo/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/demo/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/go" GOPRIVATE="" GOPROXY="https://goproxy.cn,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.16" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/demo/golang-setgroups-hang/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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3393189053=/tmp/go-build -gno-record-gcc-switches"
What did you do?
See https://github.com/weixiao-huang/golang-setgroups-hang
What did you expect to see?
client --key-path /.launch/key --server=localhost:2222
should not hang while compiled by golang 1.16.x and 1.17.x
What did you see instead?
client --key-path /.launch/key --server=localhost:2222
will hang while compiled by golang 1.16.x and 1.17.x
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 35 (26 by maintainers)
Links to this issue
Commits related to this issue
- runtime: move doAllThreadsSyscall to os_linux.go syscall_runtime_doAllThreadsSyscall is only used on Linux. In preparation of a follow-up CL that will modify the function to use other Linux-only func... — committed to golang/go by prattmic 2 years ago
- runtime/internal/syscall: new package for linux Add a generic syscall package for use by the runtime. Eventually we'd like to clean up system calls in the runtime to use more code generation and be m... — committed to golang/go by prattmic 2 years ago
- Add a test case for a deadlock. The CGO_ENABLED=0 failure mode is discussed in: https://github.com/golang/go/issues/50113 At the present time, this only passes when the psx package is compiled CG... — committed to thekevinday/kernel.org-libcap by AndrewGMorgan 2 years ago
I think we do want something like the patch in https://github.com/golang/go/issues/50113#issuecomment-1014191407. The ability for a blocking system call anywhere in the program to block execution is
AllThreadsSyscall
is a quite painful limitation, particularly since most users won’t have the full-program awareness to know if there program might ever execute a blocking system call.(Some system calls may not even be expected to block indefinitely, but expect to be woken by an action on another thread. But since we have stopped the world, that action never occurs and this thread remains blocked forever, causing a deadlock).
cc @aclements