Skip to content

runtime: infinite loop in lockextra on linux/amd64 [1.14 backport] #42635

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
Closed
gopherbot opened this issue Nov 16, 2020 · 3 comments
Closed

runtime: infinite loop in lockextra on linux/amd64 [1.14 backport] #42635

gopherbot opened this issue Nov 16, 2020 · 3 comments
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone
Go1.14.13

Comments

@gopherbot
Copy link
Contributor

@ianlancetaylor requested issue #42207 to be considered for backport to the next 1.14 minor release.

@gopherbot Please open backport issues.

This bug can cause a deadlock for programs that create threads in C code such that those threads call into Go code, if a signal is received at the wrong time. There is no workaround.

Note that CL 265759 had a bug in the test, and that CL 265778 (a test-only change) is also required.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Nov 16, 2020
@gopherbot gopherbot mentioned this issue Nov 16, 2020
Closed
@gopherbot gopherbot added this to the Go1.14.13 milestone Nov 16, 2020
@dmitshur dmitshur mentioned this issue Nov 19, 2020
Closed
@dmitshur
Copy link
Contributor

Approving per discussion in a release meeting. This backport applies to both 1.15 (#42636) and 1.14 (this issue).

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Nov 19, 2020
@gopherbot
Copy link
Contributor Author

Change https://golang.org/cl/271848 mentions this issue: [release-branch.go1.14] runtime: block signals in needm before allocating M

gopherbot pushed a commit that referenced this issue Nov 20, 2020
@ianlancetaylor
[release-branch.go1.14] runtime: block signals in needm before alloca…
9e27a08 
…ting M

Otherwise, if a signal occurs just after we allocated the M,
we can deadlock if the signal handler needs to allocate an M
itself.

For #42207
Fixes #42635

Change-Id: I76f44547f419e8b1c14cbf49bf602c6e645d8c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/265759
Trust: Ian Lance Taylor <[email protected]>
Run-TryBot: Ian Lance Taylor <[email protected]>
TryBot-Result: Go Bot <[email protected]>
Reviewed-by: Bryan C. Mills <[email protected]>
(cherry picked from commit 368c401)
Reviewed-on: https://go-review.googlesource.com/c/go/+/271848
@gopherbot
Copy link
Contributor Author

Closed by merging 9e27a08 to release-branch.go1.14.

@golang golang locked and limited conversation to collaborators Nov 20, 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.13
Development

No branches or pull requests
2 participants
@dmitshur @gopherbot