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

Closed
cwedgwood opened this issue Aug 23, 2017 · 11 comments
Closed

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

cwedgwood opened this issue Aug 23, 2017 · 11 comments
Assignees
Milestone

Comments

@cwedgwood
Copy link
Contributor

@cwedgwood cwedgwood 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

@ianlancetaylor ianlancetaylor 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

@cwedgwood cwedgwood 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

@ianlancetaylor ianlancetaylor 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

@gopherbot gopherbot 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

@odeke-em odeke-em 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

@cwedgwood cwedgwood 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

@odeke-em odeke-em commented Mar 11, 2019

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

@odeke-em

This comment has been minimized.

Copy link
Member

@odeke-em odeke-em commented Oct 1, 2019

I mailed CL https://go-review.googlesource.com/c/go/+/101036 for this change, PTAL.

@gopherbot gopherbot closed this in e79b57d Oct 2, 2019
@shawn-xdji

This comment has been minimized.

Copy link
Contributor

@shawn-xdji shawn-xdji commented Oct 9, 2019

Hi,

Just curious to know is "ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)" in the associated testcase supposed to kill the background 'go run' after 5 seconds (if without the fix from @odeke-em , it gets stuck there with my dev. environment?

If reducing the time-out value, say to 100 millisecond, the background go program could be killed, what's behind the difference?

Thanks.

@odeke-em

This comment has been minimized.

Copy link
Member

@odeke-em odeke-em commented Oct 9, 2019

@shawn-xdji

This comment has been minimized.

Copy link
Contributor

@shawn-xdji shawn-xdji commented Oct 10, 2019

Thanks @odeke-em . Furthermore, without your change is the background 'go run' supposed to be killed after 5 seconds due to time-out?

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