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

runtime: OS thread appears to be re-used despite never releasing runtime.LockOSThread() [1.11 backport] #28986

Closed
gopherbot opened this Issue Nov 28, 2018 · 4 comments

Comments

Projects
None yet
6 participants
@gopherbot
Copy link

gopherbot commented Nov 28, 2018

@ianlancetaylor requested issue #28979 to be considered for backport to the next 1.11 minor release.

@gopherbot Please open a backport issue for 1.10 and 1.11.

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Dec 19, 2018

@mknyszek, @aclements, @ianlancetaylor: Now that the fix has landed on master, do we want to backport it?

@mknyszek

This comment has been minimized.

Copy link
Contributor

mknyszek commented Dec 19, 2018

Nearly forgot. On it.

@gopherbot

This comment has been minimized.

Copy link
Author

gopherbot commented Dec 19, 2018

Change https://golang.org/cl/155117 mentions this issue: [release-branch.go1.11] runtime: don't clear lockedExt on locked M when G exits

@gopherbot

This comment has been minimized.

Copy link
Author

gopherbot commented Dec 19, 2018

Closed by merging f500f13 to release-branch.go1.11.

@gopherbot gopherbot closed this Dec 19, 2018

gopherbot pushed a commit that referenced this issue Dec 19, 2018

[release-branch.go1.11] runtime: don't clear lockedExt on locked M wh…
…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>

@julieqiu julieqiu modified the milestones: Go1.11.5, Go1.11.6 Jan 23, 2019

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