Skip to content

fatal error: bulkBarrierPreWrite: unaligned arguments [1.18 backport] #55151

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

Closed
randall77 opened this issue Sep 19, 2022 · 3 comments
Closed
Labels
CherryPickApproved Used during the release process for point releases FrozenDueToAge
Milestone

Comments

@randall77
Copy link
Contributor

@randall77 requested issue #55122 to be considered for backport to the next 1.18 minor release.

Reproducer:

package main

func main() {
	for i := 0; i < 10000; i++ {
		h(i)
		sink = make([]byte, 1024) // generate some garbage
	}
}

func h(iter int) {
	var x [32]byte
	for i := 0; i < 32; i++ {
		x[i] = 99
	}
	g(&x)
	if x == ([32]byte{}) {
		return
	}
	for i := 0; i < 32; i++ {
		println(x[i])
	}
	panic(iter)
}

//go:noinline
func g(x interface{}) {
	switch e := x.(type) {
	case *[32]byte:
		var c [32]byte
		*e = c
	case *[]byte:
		*e = nil
	}
}

var sink []byte
@randall77 randall77 added the CherryPickCandidate Used during the release process for point releases label Sep 19, 2022
@randall77 randall77 added this to the Go1.18.7 milestone Sep 19, 2022
@randall77
Copy link
Contributor Author

This issue causes a rare but serious miscompilation.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/431918 mentions this issue: [release-branch.go1.18] cmd/compile: avoid using destination pointer base type in memmove optimization

@cherrymui cherrymui added the CherryPickApproved Used during the release process for point releases label Sep 21, 2022
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Sep 21, 2022
@gopherbot
Copy link
Contributor

Closed by merging e0a364b to release-branch.go1.18.

gopherbot pushed a commit that referenced this issue Sep 21, 2022
…base type in memmove optimization

The type of the source and destination of a memmove call isn't
always accurate. It will always be a pointer (or an unsafe.Pointer), but
the base type might not be accurate. This comes about because multiple
copies of a pointer with different base types are coalesced into a single value.

In the failing example, the IData selector of the input argument is a
*[32]byte in one branch of the type switch, and a *[]byte in the other branch.
During the expand_calls pass both IDatas become just copies of the input
register. Those copies are deduped and an arbitrary one wins (in this case,
*[]byte is the unfortunate winner).

Generally an op v can rely on v.Type during rewrite rules. But relying
on v.Args[i].Type is discouraged.

Fixes #55151

Change-Id: I348fd9accf2058a87cd191eec01d39cda612f120
Reviewed-on: https://go-review.googlesource.com/c/go/+/431496
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Run-TryBot: Keith Randall <[email protected]>
Reviewed-by: Cuong Manh Le <[email protected]>
Reviewed-by: Keith Randall <[email protected]>
(cherry picked from commit e283473)
Reviewed-on: https://go-review.googlesource.com/c/go/+/431918
@golang golang locked and limited conversation to collaborators Sep 21, 2023
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 FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

3 participants