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: confusing "stack unavailable" in stack trace #5873
Labels
Milestone
Comments
We should add the creator information. We really don't have accurate information about what the goroutine is doing. It's difficult to get, because we would need to pause the thread to look at the goroutine. We used to print a stack using the PC and SP from the last time the goroutine paused and hope that it all worked out, but that can produce incorrect traces, which can be even more confusing. I would love to do something better before Go 1.2. I don't know what. |
We can set a global "panicking" flag that will tell scheduler to not schedule new goroutines, and then issue preemptall(). If the unwinder finds a running goroutine, issue preemptall() again and sleep for Xus. This should have very good chances of stopping all goroutines. The additional delay is bounded by GOMAXPROCS*Xus. |
Another example https://golang.org/issue/5831?c=15 of "stack unavailable". Alex |
Now that preemption is in, I suggest that we follow Dmitriy's idea in comment #5. However, instead of preempting during the unwinder I suggest we make the thing that starts the panic do a loop over the goroutines to preempt any that are running, before the unwind. The loop needs to report whether any were found. If any were found, sleep for 10 ms before continuing. That is all. No retry, no fallback. |
Issue #2744 has been merged into this issue. |
Owner changed to @dvyukov. |
This issue was closed by revision 01f1e3d. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: