runtime: potential deadlock cycle caused by scavenge.lock #34047
Labels
Milestone
Comments
|
Change https://golang.org/cl/191977 mentions this issue: |
|
This has the potential for reduced stability in Go 1.13. While the chance of deadlock is extremely low, when it hits you it will tend to hit you consistently, because stack depth is consistent (for example #32105). CC @aclements @gopherbot Please open a backport issue for 1.13. |
|
Backport issue(s) opened: #34150 (for 1.13). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
scavenge.lockin the runtime is in a lock cycle with several different locks, all because it may be acquired (and according to the runtime documentation, must!) after the heap lock is acquired.While the chance for deadlock is incredibly low because it could only happen as the result of an errant stack growth (which takes the slow path), or a rare allocation in the timer code, or in a rare acquisition of
sched.lockinready(), this is nonetheless a regression in stability and we should remove the potential for this lock cycle.I propose we simply move the scavenger-waking code out of gcPaceScavenger and into its own function which is then called after gcSetTriggerRatio where appropriate. There are only two callsites, so this should be no problem to do.
The text was updated successfully, but these errors were encountered: