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

os/signal: deadlock detection fails when os/signal is included #21576

Open
cwedgwood opened this issue Aug 23, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@cwedgwood
Copy link
Contributor

commented Aug 23, 2017

go1.8, go1.9-rc2

linux amd64 & go playground

including os/signal breaks deadlock detection:

package main

import _ "os/signal"

func main() {
	c := make(chan int)
	c <- 1
}

or see https://play.golang.org/p/-KF7aAeIhS as it happens there as well

this hangs

without os/signal included we get the expected deadlock detection message

@ianlancetaylor ianlancetaylor changed the title deadlock detection fails when os/signal is included os/signal: deadlock detection fails when os/signal is included Aug 23, 2017

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Aug 23, 2017

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2017

This is hard to fix. A program that has any active signal.Notify channels can not be deadlocked, since a signal could arrive at any time. So it would have to be the case that we report a deadlock only when no channels remain in signal.Notify. That is difficult because os/signal starts up a helper goroutine to wait for signals to arrive. To fix this we would have to start that helper goroutine only when Notify is called, and shut it down when Stop is called on all active channels. I don't think it's worth it for such an obscure case.

@cwedgwood

This comment has been minimized.

Copy link
Contributor Author

commented Aug 23, 2017

@ianlancetaylor understood, but as is - even if i call no functions explicitly (such as when the code is in dev/debug mode), the init functions are active here

this means to 'enable' deadlock detection i need a code-change where i remove all references to os/signal

i don't have a clean solution to propose here, i'm just highlighting a build/debug quirk that came up

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 23, 2017

I would be willing to consider a CL that starts the goroutine only when Notify is called, not at initialization time. I haven't looked too closely but I think that would be a fairly simple change and an improvement over the current situation.

@gopherbot

This comment has been minimized.

Copy link

commented Mar 16, 2018

Change https://golang.org/cl/101036 mentions this issue: os/signal: lazily start signal watch loop only on Notify

@odeke-em

This comment has been minimized.

Copy link
Member

commented Mar 16, 2018

I stumbled upon this issue as I was having dinner so I've mailed https://go-review.googlesource.com/#/c/go/+/101036. Thank you very much for the report @cwedgwood and @ianlancetaylor for the solution!

@cwedgwood

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2019

resolved some time ago, closing

@cwedgwood cwedgwood closed this Feb 8, 2019

@odeke-em odeke-em reopened this Mar 11, 2019

@odeke-em

This comment has been minimized.

Copy link
Member

commented Mar 11, 2019

This issue hasn't yet been solved. CL fixing it will be merged soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.