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: SIGSEGV in race + coverage mode [1.20 backport] #60845

Closed
gopherbot opened this issue Jun 16, 2023 · 2 comments
Closed

runtime: SIGSEGV in race + coverage mode [1.20 backport] #60845

gopherbot opened this issue Jun 16, 2023 · 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

Comments

@gopherbot
Copy link
Contributor

@prattmic requested issue #60825 to be considered for backport to the next 1.20 minor release.

@gopherbot Please open backports for 1.19 and 1.20. This bug can cause crashes on seemingly arbitrary atomic operations in race mode.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Jun 16, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 16, 2023
@gopherbot gopherbot added this to the Go1.20.6 milestone Jun 16, 2023
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/503976 mentions this issue: [release-branch.go1.20] runtime: use 1-byte load for address checking in racecallatomic

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Jun 21, 2023
@gopherbot
Copy link
Contributor Author

Closed by merging be30960 to release-branch.go1.20.

gopherbot pushed a commit that referenced this issue Jun 22, 2023
… in racecallatomic

In racecallatomic, we do a load before calling into TSAN, so if
the address is invalid we fault on the Go stack. We currently use
a 8-byte load instruction, regardless of the data size that the
atomic operation is performed on. So if, say, we are doing a
LoadUint32 at an address that is the last 4 bytes of a memory
mapping, we may fault unexpectedly. Do a 1-byte load instead.
(Ideally we should do a load with the right size, so we fault
correctly if we're given an unaligned address for a wide load
across a page boundary. Leave that for another CL.)

Fix AMD64, ARM64, and PPC64. The code already uses 1-byte load
on S390X.

Fixes #60845.
Updates #60825.

Change-Id: I3dee93eb08ba180c85e86a9d2e71b5b520e8dcf0
Reviewed-on: https://go-review.googlesource.com/c/go/+/503937
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
(cherry picked from commit 1a7709d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/503976
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Austin Clements <austin@google.com>
@golang golang locked and limited conversation to collaborators Jun 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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
Development

No branches or pull requests

2 participants