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

runtime: timer self-deadlock due to preemption point [1.14 backport] #38072

Closed
gopherbot opened this issue Mar 25, 2020 · 3 comments
Closed

runtime: timer self-deadlock due to preemption point [1.14 backport] #38072

gopherbot opened this issue Mar 25, 2020 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone
Go1.14.2

Comments

@gopherbot
Copy link
Contributor

@mknyszek requested issue #38070 to be considered for backport to the next 1.14 minor release.

@gopherbot Please open a backport to 1.14.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Mar 25, 2020
@gopherbot gopherbot mentioned this issue Mar 25, 2020
Closed
@gopherbot gopherbot added this to the Go1.14.2 milestone Mar 25, 2020
@mknyszek mknyszek mentioned this issue Mar 25, 2020
Closed
@mknyszek mknyszek self-assigned this Mar 25, 2020
@gopherbot
Copy link
Contributor Author

Change https://golang.org/cl/225521 mentions this issue: runtime: prevent preemption while timer is in timerModifying

@ianlancetaylor ianlancetaylor mentioned this issue Mar 25, 2020
Closed
@ianlancetaylor
Copy link
Member

This eliminates cases where a Go program could hang with no workaround. Cherry pick approved.

@ianlancetaylor ianlancetaylor added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Mar 25, 2020
gopherbot pushed a commit that referenced this issue Mar 25, 2020
@mknyszek @ianlancetaylor
[release-branch.go1.14] runtime: prevent preemption while timer is in…
b43b463 
… timerModifying

Currently if a goroutine is preempted while owning a timer in the
timerModifying state, it could self-deadlock. When the goroutine is
preempted and calls into the scheduler, it could call checkTimers. If
checkTimers encounters the timerModifying timer and calls runtimer on
it, then runtimer will spin, waiting for that timer to leave the
timerModifying state, which it never will.

So far we got lucky that for the most part that there were no preemption
points while timerModifying is happening, however CL 221077 seems to
have introduced one, leading to sporadic self-deadlocks.

This change disables preemption explicitly while a goroutines holds a
timer in timerModifying. Since only checkTimers (and thus runtimer) is
called from the scheduler, this is sufficient to prevent
preemption-based self-deadlocks.

For #38070
Fixes #38072

Change-Id: Idbfac310889c92773023733ff7e2ff87e9896f0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/225497
Run-TryBot: Michael Knyszek <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
(cherry picked from commit e8be350)
Reviewed-on: https://go-review.googlesource.com/c/go/+/225521
Run-TryBot: Ian Lance Taylor <[email protected]>
@gopherbot
Copy link
Contributor Author

Closed by merging b43b463 to release-branch.go1.14.

@golang golang locked and limited conversation to collaborators Mar 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Projects
None yet
Milestone
Go1.14.2
Development

No branches or pull requests
3 participants
@mknyszek @ianlancetaylor @gopherbot