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.

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

runtime,cmd/compile: apparent memory corruption in compress/flate [1.18 backport] #56751

Closed
cherrymui opened this issue Nov 15, 2022 · 2 comments
Closed

runtime,cmd/compile: apparent memory corruption in compress/flate [1.18 backport] #56751

cherrymui opened this issue Nov 15, 2022 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone
Go1.18.9

Comments

@cherrymui
Copy link
Member

Consider backporting for #54596.

This may cause (rare) GC crashes or memory corruptions. The large object case is new for Go 1.20, but it could still happen with small objects in previous releases. Thanks.
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 15, 2022
@gopherbot gopherbot added this to the Go1.18.9 milestone Nov 15, 2022
@cherrymui cherrymui added the CherryPickCandidate Used during the release process for point releases label Nov 15, 2022
@joedian joedian added the CherryPickApproved Used during the release process for point releases label Nov 16, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Nov 16, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/453255 mentions this issue: [release-branch.go1.18] runtime: make GC see object as allocated after it is initialized

@gopherbot
Copy link
Contributor

Closed by merging 3115ed2 to release-branch.go1.18.

gopherbot pushed a commit that referenced this issue Nov 25, 2022
@cherrymui
[release-branch.go1.18] runtime: make GC see object as allocated afte…
3115ed2 
…r it is initialized

When the GC is scanning some memory (possibly conservatively),
finding a pointer, while concurrently another goroutine is
allocating an object at the same address as the found pointer, the
GC may see the pointer before the object and/or the heap bits are
initialized. This may cause the GC to see bad pointers and
possibly crash.

To prevent this, we make it that the scanner can only see the
object as allocated after the object and the heap bits are
initialized. Currently the allocator uses freeindex to find the
next available slot, and that code is coupled with updating the
free index to a new slot past it. The scanner also uses the
freeindex to determine if an object is allocated. This is somewhat
racy. This CL makes the scanner use a different field, which is
only updated after the object initialization (and a memory
barrier).

Updates #54596.
Fixes #56751.

Change-Id: I2a57a226369926e7192c253dd0d21d3faf22297c
Reviewed-on: https://go-review.googlesource.com/c/go/+/449017
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit febe7b8)
Reviewed-on: https://go-review.googlesource.com/c/go/+/453255
@golang golang locked and limited conversation to collaborators Nov 25, 2023
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 compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
Go1.18.9
Development

No branches or pull requests
3 participants
@gopherbot @cherrymui @joedian