runtime/race: no goroutines fatal error when running programs under race detector #24418
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
RaceDetector
Milestone
Comments
nhooyr
changed the title
|
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.
|
ALTree
changed the title
andybons
changed the title
|
/cc @dvyukov |
andybons
added
the
NeedsInvestigation
|
The same happens if you import "C", right? |
|
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 |
|
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. |
|
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. |
|
Duplicate of #20588 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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)?What did you do?
Run the following program:
You'll get:
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.
The text was updated successfully, but these errors were encountered: