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
runtime: OS thread appears to be re-used despite never releasing runtime.LockOSThread() [1.11 backport] #28986
Labels
Milestone
Comments
gopherbot
added
the
CherryPickCandidate
Used during the release process for point releases
label
Nov 28, 2018
@mknyszek, @aclements, @ianlancetaylor: Now that the fix has landed on |
Nearly forgot. On it. |
bcmills
added
the
CherryPickApproved
Used during the release process for point releases
label
Dec 19, 2018
gopherbot
removed
the
CherryPickCandidate
Used during the release process for point releases
label
Dec 19, 2018
Change https://golang.org/cl/155117 mentions this issue: |
Closed by merging f500f13 to release-branch.go1.11. |
gopherbot
pushed a commit
that referenced
this issue
Dec 19, 2018
…en G exits When a locked M has its G exit without calling UnlockOSThread, then lockedExt on it was getting cleared. Unfortunately, this meant that during P handoff, if a new M was started, it might get forked (on most OSes besides Windows) from the locked M, which could have kernel state attached to it. To solve this, just don't clear lockedExt. At the point where the locked M has its G exit, it will also exit in accordance with the LockOSThread API. So, we can safely assume that it's lockedExt state will no longer be used. For the case of the main thread where it just gets wedged instead of exiting, it's probably better for it to keep the locked marker since it more accurately represents its state. Fixed #28986. Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f Reviewed-on: https://go-review.googlesource.com/c/155117 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
@ianlancetaylor requested issue #28979 to be considered for backport to the next 1.11 minor release.
The text was updated successfully, but these errors were encountered: