runtime/race: no goroutines fatal error when running programs under race detector

[nhooyr]

Please answer these questions before submitting your issue. Thanks!

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

go version go1.10 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/nhooyr/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/nhooyr/Programming/gopath"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.10/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.10/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7b/218sfv615xxf_w9ttnpjt0_r0000gn/T/go-build006239443=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Run the following program:

package main

import "runtime"

func main() {
	runtime.Goexit()
}

You'll get:

fatal error: no goroutines (main called runtime.Goexit) - deadlock!

runtime stack:
runtime.throw(0x106c653, 0x36)
	/usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:619 +0x81
runtime.checkdead()
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:4148 +0x31b
runtime.mput(0xc42006a000)
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:4519 +0x49
runtime.stopm()
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1945 +0xba
runtime.findrunnable(0xc420024a00, 0x0)
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:2410 +0x50c
runtime.schedule()
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:2536 +0x13b
runtime.mstart1(0x0)
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1232 +0x9e
runtime.mstart()
	/usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1188 +0x76
exit status 2

If you run with the race detector instead, then the runtime will not complain about there being no goroutines. I think that's because the race detector is running its own goroutines to detect races. I think the runtime should differentiate between them so that the race detector does not hide such serious errors.

[davecheney]

I believe this is a duplicate of a very old issue. The resolution on the previous issue was the deadlock detection is best effort, not guaranteed.

…

On 16 Mar 2018, at 13:07, Anmol Sethi ***@***.***> wrote: Please answer these questions before submitting your issue. Thanks! What version of Go are you using (go version)? go version go1.10 darwin/amd64 Does this issue reproduce with the latest release? Yes. What operating system and processor architecture are you using (go env)? GOARCH="amd64" GOBIN="" GOCACHE="/Users/nhooyr/Library/Caches/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/nhooyr/Programming/gopath" GORACE="" GOROOT="/usr/local/Cellar/go/1.10/libexec" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.10/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7b/218sfv615xxf_w9ttnpjt0_r0000gn/T/go-build006239443=/tmp/go-build -gno-record-gcc-switches -fno-common" What did you do? Run the following program: package main import "runtime" func main() { runtime.Goexit() } You'll get: fatal error: no goroutines (main called runtime.Goexit) - deadlock! runtime stack: runtime.throw(0x106c653, 0x36) /usr/local/Cellar/go/1.10/libexec/src/runtime/panic.go:619 +0x81 runtime.checkdead() /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:4148 +0x31b runtime.mput(0xc42006a000) /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:4519 +0x49 runtime.stopm() /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1945 +0xba runtime.findrunnable(0xc420024a00, 0x0) /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:2410 +0x50c runtime.schedule() /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:2536 +0x13b runtime.mstart1(0x0) /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1232 +0x9e runtime.mstart() /usr/local/Cellar/go/1.10/libexec/src/runtime/proc.go:1188 +0x76 exit status 2 If you run with the race detector instead, then the runtime will not complain about there being no goroutines. I think that's because the race detector is running its own goroutines to detect races. I think the runtime should differentiate between them so that the race detector does not hide such serious errors. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[andybons]

/cc @dvyukov

[dvyukov]

The same happens if you import "C", right?

[odeke-em]

I think this might be sort of related to an issue that I am going to work on in the next couple of days #21576. I started working on it with what seemed like a seemingly straightforward fix, but alas when cgo is enabled seems like a signal.Notify like loop is started and it won't catch deadlocks either. /cc @ianlancetaylor

[dvyukov]

We can fix cgo, we can fix signal.Notify, but then a program imports some package that starts a single background goroutine and we have the same problem. The buitin deadlock detector is really for the simplest handbook cases.

[nhooyr]

There is a difference between a background goroutine that could actually be doing something vs one that is deadlocked. If deadlocked, its a definite bug and we should detect it if possible.

[dvyukov]

Duplicate of #20588