-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: inconsistent integer arithmetic result on Go 1.22+arm64 with/without -race [1.22 backport] #68230
Comments
Change https://go.dev/cl/595696 mentions this issue: |
This issue leads to miscompilation in rare cases involving sign/zero extension and register spill/restore paths. |
…p of signed values v = ... compute some value, which zeros top 32 bits ... w = zero-extend v We want to remove the zero-extension operation, as it doesn't do anything. But if v is typed as a signed value, and it gets spilled/restored, it might be re-sign-extended upon restore. So the zero-extend isn't actually a NOP when there might be calls or other reasons to spill in between v and w. Fixes #68230 Change-Id: I3b30b8e56c7d70deac1fb09d2becc7395acbadf8 Reviewed-on: https://go-review.googlesource.com/c/go/+/595675 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Joedian Reid <joedian@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 7f90b96) Reviewed-on: https://go-review.googlesource.com/c/go/+/595696 Reviewed-by: Keith Randall <khr@google.com>
Closed by merging 45f9ded to release-branch.go1.22. |
@randall77 is it within the realm of possibility that this issue could lead to a GC crash like the one below? (perhaps in the presence of
(this is from cockroachdb/cockroach#134020) |
I guess it is possible, but not terribly likely. That fault is because the runtime's internal data is corrupted. For that to happen, we'd have to use the bug to calculate a bad offset during some |
The high 32 bit error could apply to an intermediary result, which then causes us to get an incorrect pointer that is less than 4GB away no? For example things like |
Sure, it is possible.
That particular case seems unlikely to be the problem, as a hash function would certainly be followed by a bounds check or mask. It might cause a hash miss where there should be a hit, but that shouldn't corrupt runtime state. |
@randall77 requested issue #68227 to be considered for backport to the next 1.22 minor release.
The text was updated successfully, but these errors were encountered: