runtime: code running on other threads does not show up in stack trace #4494
Labels
Comments
Smaller reproduction case, at least on a Mac:
package main
func main() {
for{}
}
The problem is that the thread that gets the signal is not the thread executing - it's a
background thread sleeping - and when it dumps the goroutine stacks it has not access to
the other threads' register sets and cannot show the stacks for the goroutines they are
running.
To fix this we would have to pick a custom signal (SIGPROF maybe), send it to all the
other threads, and make the signal handler supply the goroutine stack. I'm not even sure
if OS X can target a signal to a specific thread.
See issue #4391, which will also require intraprocess signals. Yuck.
|
issue #5873 is the half that will be done in Go 1.2. The rest (for{}) will have to wait at least until Go 1.3, if not longer. Labels changed: added go1.3maybe, removed go1.2. |
|
This issue was closed by revision 757e0de. 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.
func main() { main() } This program hangs consuming 100% CPU and unbounded memory, as expected. What is not expected is that delivering SIGQUIT to the program reveals nothing about why. Even running under gdb, interrupting, and issuing 'goroutine <id> bt' for the two goroutines 1 and 2 shows only Go scheduler and memory allocation activity, with rare exceptions. (Presumably it's not tail-optimising the call and is allocating new frames forever.) (This is a minimized testcase from a larger program in which the number of calls in the cycle was nontrivial and therefore much harder to guess at.) % go version go version devel +ab868a8f3128 Thu Nov 08 16:07:05 2012 -0500 % uname -a Linux adonovan.nyc.corp.google.com 2.6.38.8-gg987 #2 SMP Fri Sep 14 03:37:11 PDT 2012 x86_64 GNU/LinuxThe text was updated successfully, but these errors were encountered: