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: process stuck while referencing x.f when x is nil #16069
Comments
Does your program use cgo? What is your Have you tried Go 1.6.2? Go 1.6 has several fixes to signal handling. The delve information appears to be at the point where the signal occurs. The infinite loop is probably happening later. It might help to see what the goroutine and thread information look like then. We probably aren't going to be able to help very much without a way to reproduce the problem. |
Yes.
1
We are not using runtime.LockOSThread on our code or other import code I think.
Yes. I change the code to something like this:
And get this:
|
The last stack trace looks like what you want, right? As I understand it, you expect a crash, and the bug is that the program hangs instead of crashing. So it sounds like it only hangs when You didn't answer my question about Delve, but let me ask a different question. When the program is hanging, hit ^\ or (equivalently) send the process a SIGQUIT signal. That should dump a stack trace. Tell us that stack trace. Thanks. |
@ianlancetaylor I do want to answer your question about delve..But I can't because I can not go to the next step, it just frozen there.
Yes. And this time. It hangs again even with
This is output when
|
What is this goroutine?
|
@ianlancetaylor It runs this method
And panic I expected should happen inside |
ch can be nil if the two conditions for initialising the timer are not On Thu, 16 Jun 2016, 14:55 Zhiheng Huang notifications@github.com wrote:
|
That is what I want. |
If ch is nil then the code block that contains rm.retry will not be On Thu, 16 Jun 2016, 15:49 Zhiheng Huang notifications@github.com wrote:
|
@davecheney
is called by rm.retry, and it is reachable. output here |
OK, then ch isn't nil. On Thu, 16 Jun 2016, 15:55 Zhiheng Huang notifications@github.com wrote:
|
What happens if you use fmt.Println rather than println? On Thu, 16 Jun 2016, 15:57 Dave Cheney dave@cheney.net wrote:
|
@davecheney |
The issue you reported is that rather than the next line panicking, it just On Thu, 16 Jun 2016, 16:02 Zhiheng Huang notifications@github.com wrote:
|
@davecheney |
Can you please paste a complete stack trace. Thanks. On Thu, 16 Jun 2016, 16:05 Zhiheng Huang notifications@github.com wrote:
|
@davecheney I have pasted above.
If it hung, it will be like this:
|
Goroutine 7, your cgo code is the one consuming all the CPU. On Thu, 16 Jun 2016, 16:09 Zhiheng Huang notifications@github.com wrote:
|
I'm sorry but I don't think there is a bug in go. In the cases where the On Thu, 16 Jun 2016, 16:16 Dave Cheney dave@cheney.net wrote:
|
@davecheney @ianlancetaylor Thanks for your help! |
The new go build -msan flag (go 1.6 or later) may help debug issues with https://golang.org/doc/go1.6#go_command On Thu, 16 Jun 2016, 16:37 Zhiheng Huang notifications@github.com wrote:
|
@davecheney Thanks! Will try it. |
Closing because it sounds like the problem is not one that can be fixed in the Go distribution. |
Please answer these questions before submitting your issue. Thanks!
go version
)?go version go1.5.4 linux/amd64
go env
)?Some info got from delve.
And then cpu usage is 99.9%. And I can not term process without
kill -9
.I tried to write a simple piece of code to reproduce this but I can't.
Could you give me some clues of this?
The text was updated successfully, but these errors were encountered: