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

Received panic throw("signal_recv: inconsistent state") on Mac while debugging #42619

Open
calbot opened this issue Nov 15, 2020 · 7 comments
Open

Comments

@calbot
Copy link

@calbot calbot commented Nov 15, 2020

$ go version
go version go1.15.5 darwin/amd64

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/cschut/Library/Caches/go-build"
GOENV="/Users/cschut/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/cschut/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cschut/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/cschut/Documents/workspace-neon/ss-fastapi/streamergo/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ww/vhl9dm7s0gs2dgs61nzkvnnh0000gr/T/go-build377450755=/tmp/go-build -gno-record-gcc-switches -fno-common"

Received
throw("signal_recv: inconsistent state")

runtime.fatalthrow (/usr/local/go/src/runtime/panic.go:1162)
runtime.throw (/usr/local/go/src/runtime/panic.go:1116)
os/signal.signal_recv (/usr/local/go/src/runtime/sigqueue.go:140)
os/signal.loop (/usr/local/go/src/os/signal/signal_unix.go:23)
runtime.goexit (/usr/local/go/src/runtime/asm_amd64.s:1374)

Not very consistently reproducible. I've had it happen a handful of times.
It doesn't look like this should be possible given how that sig.state is only changed with atomic functions.

I'm using github.com/panjf2000/gnet which uses kqueues. I'm not sure if that could be part of the problem somehow.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Nov 15, 2020

Thank you for raising this issue. Before we can investigate further you will need to provide us with instructions for how to reproduce the issue. If you can provide a program which demonstrates the issue that would be ideal.

@devfos
Copy link

@devfos devfos commented Nov 16, 2020

here?

@calbot
Copy link
Author

@calbot calbot commented Nov 16, 2020

Unfortunately, the code it happened in is closed source. If I'm able to reproduce it again I'll try to create an example.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Nov 16, 2020

@calbot I understand. It's going to be tricky to debug this without a way to reproduce it. In the interim, would you please make sure that you code passes all tests under the race detector, and deploy a race enable version to your production traffic to verify that there are no data races in you program. Thank you

See https://blog.golang.org/race-detector .

@segevfiner
Copy link
Contributor

@segevfiner segevfiner commented Nov 16, 2020

This happens to me somewhat often too. Proprietary code also sadly, and I wasn't able to reproduce it yet standalone. One trigger seems to be changing breakpoints while a debugged Go program is still running under Vs Code with vscode-go. I think it sends a SIGINT so it can change the breakpoints and immediately resumes. It happens more often while debugging multiple programs at once.

@calbot
Copy link
Author

@calbot calbot commented Nov 19, 2020

I did have a data race. I'll see if the problem still happens now that I've fixed that.

@davecheney
Copy link
Contributor

@davecheney davecheney commented Nov 19, 2020

Glad you found it. Please be sure to close this issue when you’ve confirmed the issue is gone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants