Open munnerz opened 4 years ago
To clarify, we don't typically run go vet
with GOOS/GOARCH parameters, however, we use Bazel for our builds and recently enabled nogo checks.
We also use the --platforms
flag to build for many different architectures during our builds, and since nogo runs at bazel build
time, it sets GOOS and GOARCH according to this --platforms
flag, hence go vet
is being invoked with these flags too.
On another note, I'm unsure what effect GOOS and GOARCH has on go vet
... Whilst this bug is something that should be addressed in Go as a panic is never good, I do wonder if Bazel should be invoking these targets in this way at all...
Setting GOOS
and GOARCH
may affect which files are loaded and which are excluded by build constraints. go vet
and nogo both need to take that into account or they won't be able to load correct type information. They also both need to build a list of type sizes, which varies across platforms.
I'm not sure if atomicalign
takes these flags into account. Most analyses would just look at the type information that was loaded and passed in, but this one may work differently depending on the alignment constraints of the target platform.
I'm not sure if
atomicalign
takes these flags into account. Most analyses would just look at the type information that was loaded and passed in, but this one may work differently depending on the alignment constraints of the target platform.
Yes exactly, atomicalign
is a no-op on platforms that are not affected by the atomic BUG.
Also as this analyzer is looking for architecture-specific alignment, it should exclusively run on the target architecture, and not by overriding GOOS
not GOARCH
That being said, it should not crash either. I can look into that (I worked on that analyzer)
The crash is not due to the fact that atomicalign
was run with GOOS/GOARCH != go env GOOS/GOARCH
. In fact atomicalign
is not correctly handling the use of sync/atomic
functions on global variables exported from another package.
I'm currently preparing a fix that will correctly handle this case.
Awesome, thank you!
Change https://golang.org/cl/207289 mentions this issue: go/analysis/passes/atomicalign: handle various selector types
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Attempting to run the
atomicalign
go vet plugin withGOOS=linux
andGOARCH=arm
againstk8s.io/apiserver/pkg/server
at ref bfa5e2e684ad413c22fd0dab55b2592af1ead049 causes a panic. This panic does not occur onlinux/amd64
,darwin/amd64
orlinux/arm64
.Script to reproduce:
What did you expect to see?
The govet check pass consistently on all platforms
What did you see instead?
cc @matloob @jayconrod