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: stack traces for active goroutines on other threads #2744

Closed
alberts opened this issue Jan 20, 2012 · 6 comments
Closed

runtime: stack traces for active goroutines on other threads #2744

alberts opened this issue Jan 20, 2012 · 6 comments

Comments

@alberts
Copy link
Contributor

alberts commented Jan 20, 2012

What steps will reproduce the problem?

We had two instances of a process stuck in an infinite loop. Probably in the same place.
Killing one with SIGQUIT gave stack traces for all goroutines and I could see the
problem.

Here's an abridged version of the stack dump. Not sure how to reproduce this reliably
yet.

SIGQUIT: quit
PC=0x418209
goroutine 1 [running]:

!!! This was empty !!!

goroutine 2 [syscall]:
ib._Cfunc_ibv_get_async_event(0x410ddc0, 0xf8481b2800)

goroutine 4 [runnable]:
syscall.Syscall6()
syscall.EpollWait(0xf80000000d, 0xf84004a170, 0xa0000000a, 0x2710, 0xc, ...)

goroutine 5 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf840003140, 0xf84000e060, 0xb)

goroutine 6 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf8400031e0, 0xf84000e060, 0xb)

goroutine 7 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf840003280, 0xf84000e060, 0xb)

goroutine 8 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf840003320, 0xf84000e060, 0xb)

goroutine 9 [select]:
actor.(*actor).run(0xf84852c930, 0x7fd115b8ef98)

goroutine 10 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf8400035a0, 0xf84000e060, 0xb)

goroutine 11 [chan receive]:
net.(*pollServer).WaitRead(0xf8481b5380, 0xf840003aa0, 0xf84000e060, 0xb)

goroutine 12 [sleep]:
time.Sleep(0x2540be400, 0x40049300)

goroutine 13 [runnable]:
created by addtimer
go/src/pkg/runtime/ztime_amd64.c:68

goroutine 14 [runnable]:
syscall.Syscall()
foo/syscall.Poll(0xf848547fa0, 0x100000001, 0x12a0, 0x0, 0x0, ...)

rax     0xfffffffffffffffc
rbx     0xac7e68
rcx     0xffffffffffffffff
rdx     0x0
rdi     0xac8708
rsi     0x0
rbp     0x7fd115b90f30
rsp     0x7fff5dee1c00
r8      0x0
r9      0x0
r10     0x0
r11     0x246
r12     0x7b9ce0
r13     0xa
r14     0x0
r15     0x0
rip     0x418209
rflags  0x246
cs      0x33
fs      0x0
gs      0x0

What is the expected output?

stacktraces for all goroutines

What do you see instead?

no stacktrace for the running goroutine #1

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which revision are you using?  (hg identify)

tip
@rsc
Copy link
Contributor

rsc commented Jan 20, 2012

Comment 1:

This happens when you get a signal and the
running goroutine is on a thread != the thread
handling the signal.
To fix this we will need to have the threads sending
each other signals.  Sigh.

@rsc
Copy link
Contributor

rsc commented Jan 24, 2012

Comment 2:

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

Owner changed to builder@golang.org.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Mar 6, 2012

Comment 3:

I don't want to start sending threads signals before Go 1.
The signal handling is still not stable on FreeBSD and maybe elsewhere.

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

@rsc
Copy link
Contributor

rsc commented Sep 12, 2012

Comment 4:

Labels changed: added go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Mar 12, 2013

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 6:

Status changed to Duplicate.

Merged into issue #5873.

@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

3 participants