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.

Sign up for GitHub

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

Jump to bottom

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

Closed
calbot opened this issue Nov 15, 2020 · 8 comments
Closed

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

calbot opened this issue Nov 15, 2020 · 8 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@calbot
Copy link

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

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.

@davecheney davecheney added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 15, 2020
@devfos
Copy link

devfos commented Nov 16, 2020

here?

@calbot
Copy link
Author

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

@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 commented Nov 16, 2020 •
edited

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 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

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

@ALTree
Copy link
Member

ALTree commented Jun 18, 2021

Caused by a data race, closing.

@ALTree ALTree closed this as completed Jun 18, 2021
@golang golang locked and limited conversation to collaborators Jun 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@davecheney @ALTree @calbot @gopherbot @segevfiner @devfos