runtime: fatal error: unexpected signal during runtime execution #16331
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
ianlancetaylor
changed the title
|
Does your program use cgo or the unsafe package? Is there a way that we can recreate the problem ourselves? CC @aclements |
|
The program doesn't use cgo but it does import a 3rd party library which imports unsafe. Currently we don't make use of any of its functionality which use unsafe. The problem can't be 100% reproduced but in Gitlab CI it fails quite often and retrying over and over again eventual fixes it i.e. the error doesn't pop-up. |
|
Are you able to try the program with the 1.7 release candidate? |
|
I have added another ci phase to test against 1.7. The very first test seems promising, i.e. the error occurred in 1.6 but not 1.7. Will get back with more data. |
|
The problem just reoccurred with 1.7 as well. |
|
What is the backtrace with 1.7? |
|
|
We have managed to figure how to solve the problem but not sure of it's the cause. The solution's surprisingly simple and wierd The problem occurs when we have this pattern: if err := <-errChan; err != nil {
defer Foobar()
logrus.WithFields(logrus.Fields{}).Error("")
return nil, whatever
} else {
....
}And this fixes it if err := <-errChan; err != nil {
logrus.WithFields(logrus.Fields{}).Error("")
defer Foobar()
return nil, whatever
} else {
....
}i.e. just changing the position of the Sole credit for discovering the work around goes to @linzhiqi |
quentinmit
added
the
NeedsInvestigation
|
I did some tracking of this in #17471 before realizing I'd filed a duplicate. I have an easy and reliable way to reproduce it and I believe I have a fix, which I'll send shortly (assuming it passes all.bash). |
|
CL https://golang.org/cl/31138 mentions this issue. |
|
After upgrading to macOS Sierra I'm seeing the same issue. Here's the stack trace I'm getting from trying to run an appengine app: |
|
@code4ghana, you're commenting on a closed issue. Closed issues aren't tracked. Also, this had fixes for Go 1.8, not Go 1.7. |
|
CL https://golang.org/cl/35638 mentions this issue. |
gopherbot
pushed a commit
that referenced
this issue
Jan 25, 2017
…n calls Fixes #18333 (backport) getArgInfo for reflect.makeFuncStub and reflect.methodValueCall is necessarily special. These have dynamically determined argument maps that are stored in their context (that is, their *funcval). These functions are written to store this context at 0(SP) when called, and getArgInfo retrieves it from there. This technique works if getArgInfo is passed an active call frame for one of these functions. However, getArgInfo is also used in tracebackdefers, where the "call" is not a true call with an active stack frame, but a deferred call. In this situation, getArgInfo currently crashes because tracebackdefers passes a frame with sp set to 0. However, the entire approach used by getArgInfo is flawed in this situation because the wrapper has not actually executed, and hence hasn't saved this metadata to any stack frame. In the defer case, we know the *funcval from the _defer itself, so we can fix this by teaching getArgInfo to use the *funcval context directly when its available, and otherwise get it from the active call frame. While we're here, this commit simplifies getArgInfo a bit by making it play more nicely with the type system. Rather than decoding the *reflect.methodValue that is the wrapper's context as a *[2]uintptr, just write out a copy of the reflect.methodValue type in the runtime. Fixes #16331. Fixes #17471. Change-Id: I81db4d985179b4a81c68c490cceeccbfc675456a Reviewed-on: https://go-review.googlesource.com/31138 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-on: https://go-review.googlesource.com/35638 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Paniced: |
|
@AlfredChenxf old closed issues are not tracked. Please open a new issue for your problem. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
go version)?go version go1.6 darwin/amd64and go 1.6 officially available on Docker hubgo env)?I have seen this problem on the system described below
and also while running on Gitlab CI i.e. inside Docker (Linux and x86_64)
The error comes up (pseudo)randomly while running tests (
go go test -race -p 4 -tags 'test' smarpshare/...).Expect the test not to fail because of
fatal error: unexpected signal during runtime executionThe text was updated successfully, but these errors were encountered: