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.

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

Closed
alexbrainman opened this issue Jul 12, 2013 · 20 comments
Closed

runtime: confusing "stack unavailable" in stack trace #5873

alexbrainman opened this issue Jul 12, 2013 · 20 comments
Milestone

Comments

@alexbrainman
Copy link
Member

C:\go\root\src>hg id
26f441a1f78b tip

C:\go\root\src>go test runtime -run=Parallelism -timeout=2s
panic: test timed out

goroutine 25 [running]:
testing.alarm()
        C:/go/root/src/pkg/testing/testing.go:574 +0x45
created by time.goFunc
        C:/go/root/src/pkg/time/sleep.go:122 +0x46

goroutine 1 [chan receive]:
testing.RunTests(0x5fb324, 0x7111e0, 0x41, 0x41, 0x1)
        C:/go/root/src/pkg/testing/testing.go:442 +0x6a0
testing.Main(0x5fb324, 0x7111e0, 0x41, 0x41, 0x7121a0, ...)
        C:/go/root/src/pkg/testing/testing.go:373 +0x6a
main.main()
        C:/DOCUME~1/brainman/LOCALS~1/Temp/go-build399409803/runtime/_test/_testmain.go:419 +0x82

goroutine 4 [chan receive]:
runtime_test.TestGoroutineParallelism(0x10eb82a0)
        c:/go/root/src/pkg/runtime/proc_test.go:115 +0x123
testing.tRunner(0x10eb82a0, 0x7113e4)
        C:/go/root/src/pkg/testing/testing.go:361 +0x88
created by testing.RunTests
        C:/go/root/src/pkg/testing/testing.go:441 +0x685

goroutine 22 [running]:
        goroutine running on other thread; stack unavailable

goroutine 23 [running]:
        goroutine running on other thread; stack unavailable

goroutine 24 [running]:
        goroutine running on other thread; stack unavailable
FAIL    runtime 2.281s

C:\go\root\src>
@rsc
Copy link
Contributor

rsc commented Jul 12, 2013

Comment 1:

I'm sorry, but what is confusing about it?
The goroutine is running on another thread; we do not know its stack.

@alexbrainman
Copy link
Member Author

Comment 2:

The purpose of stack trace is to tell me what is happening.
goroutine 22 [running]:
        goroutine running on other thread; stack unavailable
is not helping any. What is "goroutine 22" doing? Who created it? So this output raises
more questions then it answers them.
Alex

@rsc
Copy link
Contributor

rsc commented Jul 12, 2013

Comment 3:

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.

@alexbrainman
Copy link
Member Author

Comment 4:

"Creator information" will help.
The way these are now, I would rather no one see them at all (maybe Go team excepted).
You will have more questions with nothing to tell people.
Alex

@dvyukov
Copy link
Member

dvyukov commented Jul 15, 2013

Comment 5:

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.

@dominikh
Copy link
Member

Comment 6:

The other day I've had "goroutine running on other thread; stack unavailable" for the
[running] goroutine, which was especially frustrating because I sent SIGQUIT to the
process to see where my program was stuck (an infinite loop).

@remyoudompheng
Copy link
Contributor

Comment 7:

Or can we use something like the SIGPROF handler ?

@alexbrainman
Copy link
Member Author

Comment 8:

Another example https://golang.org/issue/5831?c=15 of "stack
unavailable".
Alex

@rsc
Copy link
Contributor

rsc commented Jul 29, 2013

Comment 9:

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.

@dvyukov
Copy link
Member

dvyukov commented Jul 29, 2013

Comment 10:

Sounds good

@rsc
Copy link
Contributor

rsc commented Jul 29, 2013

Comment 12:

This applies not just for panics but also for runtime.Stack with all=true.

@dvyukov
Copy link
Member

dvyukov commented Jul 29, 2013

Comment 13:

runtime.Stack(all=true) stops the world, so it must work already.

@rsc
Copy link
Contributor

rsc commented Jul 29, 2013

Comment 14:

perfect

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 15:

Labels changed: added priority-later, go1.2, removed priority-triage.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 16:

Issue #2744 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 17:

Labels changed: added feature.

@dvyukov
Copy link
Member

dvyukov commented Jul 31, 2013

Comment 18:

Owner changed to @dvyukov.

@rsc
Copy link
Contributor

rsc commented Aug 2, 2013

Comment 19:

Okay, preemption seems to be working. Let's put this in for the stack traces and then I
think we are done with things like stacks and preemption for Go 1.2.

@dvyukov
Copy link
Member

dvyukov commented Aug 8, 2013

Comment 20:

Status changed to Started.

@dvyukov
Copy link
Member

dvyukov commented Aug 9, 2013

Comment 21:

This issue was closed by revision 01f1e3d.

Status changed to Fixed.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants