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.

Sign up for GitHub

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

Jump to bottom

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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.14

Comments

@cwedgwood
Copy link
Contributor

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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 23, 2017
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Aug 23, 2017
@ianlancetaylor
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link

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

@odeke-em
Copy link
Member

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!

@odeke-em odeke-em self-assigned this Mar 16, 2018
@odeke-em odeke-em mentioned this issue Mar 28, 2018
Closed
@cwedgwood
Copy link
Contributor Author

resolved some time ago, closing

@odeke-em odeke-em reopened this Mar 11, 2019
@odeke-em
Copy link
Member

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

@odeke-em odeke-em modified the milestones: Unplanned, Go1.13 Mar 11, 2019
@njsmith njsmith mentioned this issue Jun 7, 2019
Open
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@odeke-em
Copy link
Member

odeke-em commented Oct 1, 2019

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

@shawndx
Copy link
Contributor

shawndx 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
Copy link
Member

odeke-em commented Oct 9, 2019 via email

@shawndx
Copy link
Contributor

shawndx 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?

@bcmills bcmills mentioned this issue Oct 11, 2019
Closed
@golang golang locked and limited conversation to collaborators Oct 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
6 participants
@cwedgwood @andybons @ianlancetaylor @odeke-em @gopherbot @shawndx