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

Jump to bottom

runtime: "runtime·lock: lock count" fatal error when cgo is enabled [1.18 backport] #56308

Closed
gopherbot opened this issue Oct 18, 2022 · 2 comments
Closed

runtime: "runtime·lock: lock count" fatal error when cgo is enabled [1.18 backport] #56308

gopherbot opened this issue Oct 18, 2022 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone
Go1.18.8

Comments

@gopherbot
Copy link

@prattmic requested issue #56243 to be considered for backport to the next 1.18 minor release.

@gopherbot Please backport to 1.18 and 1.19

This issue is not new but can cause random memory corruption in any program that has a goroutine exit with LockOSThread set.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Oct 18, 2022
@gopherbot gopherbot mentioned this issue Oct 18, 2022
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Oct 18, 2022
@gopherbot gopherbot added this to the Go1.18.8 milestone Oct 18, 2022
@gopherbot
Copy link
Author

Change https://go.dev/cl/443816 mentions this issue: [release-branch.go1.18] runtime: always keep global reference to mp until mexit completes

@dr2chase dr2chase added the CherryPickApproved Used during the release process for point releases label Oct 19, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Oct 19, 2022
@gopherbot
Copy link
Author

Closed by merging 2c2952a to release-branch.go1.18.

gopherbot pushed a commit that referenced this issue Oct 24, 2022
@prattmic @heschi
[release-branch.go1.18] runtime: always keep global reference to mp u…
2c2952a 
…ntil mexit completes

Ms are allocated via standard heap allocation (`new(m)`), which means we
must keep them alive (i.e., reachable by the GC) until we are completely
done using them.

Ms are primarily reachable through runtime.allm. However, runtime.mexit
drops the M from allm fairly early, long before it is done using the M
structure. If that was the last reference to the M, it is now at risk of
being freed by the GC and used for some other allocation, leading to
memory corruption.

Ms with a Go-allocated stack coincidentally already keep a reference to
the M in sched.freem, so that the stack can be freed lazily. This
reference has the side effect of keeping this Ms reachable. However, Ms
with an OS stack skip this and are at risk of corruption.

Fix this lifetime by extending sched.freem use to all Ms, with the value
of mp.freeWait determining whether the stack needs to be freed or not.

For #56243.
Fixes #56308.

Change-Id: Ic0c01684775f5646970df507111c9abaac0ba52e
Reviewed-on: https://go-review.googlesource.com/c/go/+/443716
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit e252dcf)
Reviewed-on: https://go-review.googlesource.com/c/go/+/443816
Reviewed-by: Austin Clements <austin@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
Go Compiler / Runtime
Status: Done
Milestone
Go1.18.8
Development

No branches or pull requests
2 participants
@dr2chase @gopherbot