Closed as not planned
Description
What version of Go are you using (go version
)?
go version go1.19.3 windows/amd64
Does this issue reproduce with the latest release?
I believe 1.19.3 to be the latest release at the moment, so yes.
What operating system and processor architecture are you using (go env
)?
go env
Output
set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\jpenn\AppData\Local\go-build set GOENV=C:\Users\jpenn\AppData\Roaming\go\env set GOEXE=.exe set GOEXPERIMENT= set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\jpenn\go\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\jpenn\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Program Files\Go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64 set GOVCS= set GOVERSION=go1.19.3 set GCCGO=gccgo set GOAMD64=v1 set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=L:\Work\scratch\tmp\deadlock-example\go.mod set GOWORK= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\jpenn\AppData\Local\Temp\go-build4217524297=/tmp/go-build -gno-record-gcc-switches
What did you do?
See the attached zip file. There are 4 versions of the same program. Version A triggers the deadlock detector. I wanted to test this program with the deadlock detector disabled but AFAIK there is no explicit way to do that, so I created 3 other versions of the program (B, C, and D from the zip file) which avoid the deadlock detector in various ways.
- Version A is the original version of the program which causes the false positive deadlock detection
- Version B does
include "C"
, which as far as I can tell, disables the deadlock detector, even if there is no actual C code. This version of the program works as expected, proving that it is not a true deadlock. - Version C of the program "distracts" the deadlock detector by starting a 2nd goroutine that does
time.Sleep()
in a loop. This version of the program works as expected. - Version D of the program "distracts" the deadlock detector by starting a TCP listener on a random port in a 2nd goroutine. This version of the program works as expected.
What did you expect to see?
Watching for events... got an event got an event got an event
Note that you do have to wait for something on your Windows computer to actually generate an event. Manually checking for Windows updates is a fairly easy way to trigger one, though be warned the button to check for updates is de-bounced to about once per minute.
What did you see instead?
Watching for events... fatal error: all goroutines are asleep - deadlock! goroutine 1 [select]: main.main() L:/Work/scratch/tmp/deadlock-example/a/version-a.go:19 +0x167 exit status 2