你正在使用的Go版本是什么( go version )?
$ go version 1.13这个问题在最新版本的发布中是否会重现？
是的
你正在使用什么操作系统和处理器架构( go env )?
go env 输出
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/james/Library/Caches/go-build"
GOENV="/Users/james/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/james/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/james/go/src/k8s.io/apiserver/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/l9/dkb2dtzj0cj6my4hm0t1hf6m0000gn/T/go-build247262007=/tmp/go-build -gno-record-gcc-switches -fno-common"你做了什么？
尝试使用 atomicalign go vet插件与 GOOS=linux 和 GOARCH=arm 在 k8s.io/apiserver/pkg/server 上进行对比，但在 ref bfa5e2e684ad413c22fd0dab55b2592af1ead049 处会导致恐慌。在 linux/amd64 、 darwin/amd64 或 linux/arm64 上不会出现这种情况。
复现问题的脚本：
#!/usr/bin/env bash
tmp=$(mktemp -d)
cd "$tmp"
mkdir atomicalign
cd atomicalign
go mod init atomicalign
cat <<EOF > main.go
// The atomicalign command runs the atomicalign analyzer.
package main
import (
"golang.org/x/tools/go/analysis/passes/atomicalign"
"golang.org/x/tools/go/analysis/multichecker"
)
func main() { multichecker.Main(atomicalign.Analyzer) }
EOF
# Build atomicalign entrypoint binary
go build .
cd ../
git clone https://github.com/kubernetes/apiserver.git
cd apiserver
git checkout bfa5e2e684ad413c22fd0dab55b2592af1ead049
## This command should pass
# GOOS=linux GOARCH=arm64 ../atomicalign/atomicalign ./pkg/server
## This command fails
GOOS=linux GOARCH=arm ../atomicalign/atomicalign ./pkg/server你期望看到什么？
govet检查在所有平台上都能通过
你看到了什么？
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x1196742]
goroutine 5848 [running]:
go/types.(*Selection).Obj(...)
/usr/local/Cellar/go/1.13/libexec/src/go/types/selection.go:56
golang.org/x/tools/go/analysis/passes/atomicalign.check64BitAlignment(0xc001825540, 0xc00029a5a6, 0x9, 0x13f20e0, 0xc000aa9f80)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/passes/atomicalign/atomicalign.go:87 +0xb2
golang.org/x/tools/go/analysis/passes/atomicalign.run.func1(0x13ed420, 0xc0001ecac0)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/passes/atomicalign/atomicalign.go:65 +0x172
golang.org/x/tools/go/ast/inspector.(*Inspector).Preorder(0xc001b9f0a0, 0xc000032ce8, 0x1, 0x1, 0xc0004becd8)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/ast/inspector/inspector.go:77 +0x9f
golang.org/x/tools/go/analysis/passes/atomicalign.run(0xc001825540, 0xc001c3da90, 0x15ebac0, 0xc001b96ad8, 0x203000)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/passes/atomicalign/atomicalign.go:42 +0x158
golang.org/x/tools/go/analysis/internal/checker.(*action).execOnce(0xc00183d040)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/internal/checker/checker.go:646 +0x6fa
sync.(*Once).doSlow(0xc00183d040, 0xc000032f90)
/usr/local/Cellar/go/1.13/libexec/src/sync/once.go:66 +0xe3
sync.(*Once).Do(...)
/usr/local/Cellar/go/1.13/libexec/src/sync/once.go:57
golang.org/x/tools/go/analysis/internal/checker.(*action).exec(0xc00183d040)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/internal/checker/checker.go:565 +0x60
golang.org/x/tools/go/analysis/internal/checker.execAll.func1(0xc00183d040)
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/internal/checker/checker.go:553 +0x34
created by golang.org/x/tools/go/analysis/internal/checker.execAll
/Users/james/go/pkg/mod/golang.org/x/tools@v0.0.0-20191001184121-329c8d646ebe/go/analysis/internal/checker/checker.go:559 +0x119cc @matloob@jayconrod
6条答案
按热度按时间enxuqcxy1#
为了澄清，我们通常不会在构建中使用带有GOOS/GOARCH参数的
go vet,但是我们使用Bazel进行构建，并最近启用了nogo检查。在构建过程中，我们还会使用
--platforms标志来为许多不同的架构构建，由于nogo在bazel build时间运行，它根据这个--platforms标志设置GOOS和GOARCH,因此也使用了这些标志调用go vet。另外，我不确定GOOS和GOARCH对
go vet有什么影响...虽然这个bug应该在Go中解决，因为恐慌永远不是好事，但我确实想知道Bazel是否应该以这种方式调用这些目标。rxztt3cl2#
设置
GOOS和GOARCH可能会影响加载哪些文件以及被构建约束排除哪些文件。go vet和 nogo 都需要考虑到这一点，否则它们将无法加载正确的类型信息。此外，它们还需要构建一个跨平台的类型大小列表。我不确定
atomicalign是否会考虑这些标志。大多数分析只会查看加载并传递的类型信息，但这个可能会根据目标平台的对齐约束而有所不同。2fjabf4q3#
我不确定
atomicalign是否考虑了这些标志。大多数分析只会查看加载和传递的类型信息，但这个可能会根据目标平台的对齐约束而有所不同。是的，
atomicalign在不受原子BUG影响的平台上是一个无操作。此外，由于这个分析器正在寻找特定于架构的对齐，它应该仅在目标架构上运行，而不是通过覆盖
GOOS而不是GOARCH来运行。话虽如此，它也不应该崩溃。
我可以调查一下(我曾经参与过这个分析器的开发)
7vux5j2d4#
崩溃不是由于
atomicalign与GOOS/GOARCH != go env GOOS/GOARCH一起运行造成的。事实上，atomicalign没有正确处理在另一个包中导出的全局变量上使用sync/atomic函数的情况。我目前正在准备一个修复方案，以便正确处理这种情况。
ohtdti5x5#
太棒了，谢谢你！
ux6nzvsh6#
https://golang.org/cl/207289提到了这个问题：
go/analysis/passes/atomicalign: handle various selector types