-
Notifications
You must be signed in to change notification settings - Fork 18k
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
runtime: panic: unexpected return pc for runtime.heapBitsSetType #38851
Comments
Is it feasible for you to test the current release (1.14.2)? Thanks. |
Pretty easy to try but we've only seen this crash once so far; I don't have a reliable repro scenario. Any hints as to what might cause it? |
Have done 5 or so runs on go v1.14 without repro yet. I did get another repro on 1.13.7 with the same panic but a different named function. I checked how we use profiling and it looks like we don't enable by default; it's only enabled when sending a signal. The area of code that seems to trigger the panic is deep in a library that's a transient dependency. Looks like we call through the |
I have been chipping away at this for a few weeks; I made a CI job that runs 20 hours of our FV tests, I get a failure in one in 2 runs. Roughly half the failures are like this one, the other half are nil pointer panics from some nearby code. I set up the job to dump a core file if it fails. The stack of the failing goroutine seems to be corrupted somehow. The leaf function's stack frame looks sane but one or two levels up dlv can't seem to read; then further up it can read again. |
Since this looks like memory corruption, I just want to mention the usual comments: make sure to try the race detector (https://golang.org/doc/articles/race_detector.html) and take a close look at any of your code that uses unsafe or cgo to make sure that there aren't any memory errors. I see that nobody answered your question from earlier:
Memory profiling does not cause random panics. What that comment means is that there are two different cases to consider when we trace the stack. 1) We might be doing a backtrace because of a profiling interrupt. In that case we might fail to identify the function because the signal was delivered while executing C code or in some other unusual location. We just return with whatever stack backtrace we were able to collect. 2) We might be doing a backtrace in order to collect stack pointers during a garbage collection. In that case we know for sure that we are executing normal Go code, so a failure to identify a function indicates a serious error. So we crash. You are seeing the latter case. It doesn't have anything to do with memory profiling. The problem is that your stack memory has been corrupted somehow. |
I haven't seen a repro of this for some time (we moved to Go v1.15 a while back). Possible that it's been fixed or that the code has shuffled so as not to expose the issue. |
Thanks for following up. Closing. Please comment if you see another occurrence. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
I don't know yet, it's intermittent
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran a large test FV suite for our application (approximately 900 tests, each of which starts and stops multiple copies of our application).
What did you expect to see?
A clean run.
What did you see instead?
One of the tests panicked in the go runtime very soon after our app started; full stack trace from the panic is in the details below. I don't really understand the message of the panic so it's hard to guess what other diagnostics might be useful.
Looking at the chunk of code that generates the panic there's a comment
Does that mean that this might be caused by a profiling interrupt during a GC? Does that refer to go's built-in profiling mechanisms; I think we run with memory profiling turned on by default since it's useful and low overhead but if it causes random panics then we may be forced to turn it off.
The text was updated successfully, but these errors were encountered: