ld: segfault due to nil pointer on FreeBSD/amd64

[SamWhited]

What version of Go are you using (go version)?

$ go version
go1.15.5 freebsd/amd64

Does this issue reproduce with the latest release?

Unsure, the new linker code likely doesn't have the same problem but I cannot reproduce it again on go1.15.5 either and don't see how it's possible at all.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/build/.cache/go-build"
GOENV="/home/build/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOINSECURE=""
GOMODCACHE="/home/build/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="freebsd"
GOPATH="/home/build/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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=/tmp/go-build938203918=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Ran tests with go test -v -cover ./..., full test run including failure available here:

https://builds.sr.ht/~samwhited/job/344541#task-setup

What did you see instead?

# mellium.im/xmpp/internal/marshal.test
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x3a pc=0x520b22]

goroutine 1 [running]:
cmd/link/internal/loader.(*Loader).migrateAttributes(0xc00063e000, 0x4a2, 0x1a)
	/usr/local/go/src/cmd/link/internal/loader/loader.go:2655 +0x62
cmd/link/internal/loader.loadObjFull(0xc00063e000, 0xc000642240, 0xc0018c0000)
	/usr/local/go/src/cmd/link/internal/loader/loader.go:2750 +0x127
cmd/link/internal/loader.(*Loader).LoadFull(0xc00063e000, 0x86c760, 0xc00000c120, 0x0)
	/usr/local/go/src/cmd/link/internal/loader/loader.go:2156 +0xf77
cmd/link/internal/ld.(*Link).loadlibfull(0xc000069880, 0xc001650000, 0x130bb, 0x130bb, 0x270000)
	/usr/local/go/src/cmd/link/internal/ld/lib.go:2835 +0x73
cmd/link/internal/ld.Main(0x86c760, 0x20, 0x20, 0x1, 0x7, 0x10, 0x0, 0x0, 0x6d87b2, 0x1b, ...)
	/usr/local/go/src/cmd/link/internal/ld/main.go:341 +0x18cc
main.main()
	/usr/local/go/src/cmd/link/main.go:68 +0x1dc
FAIL	mellium.im/xmpp/internal/marshal [build failed]

I cannot see how this would be possible at that point in the code (there is a check that the symbol is not nil and if the loader were nil it would have paniced way before that), and SSHing into the build machine and running tests again I am unable to reproduce the problem.

[thanm]

Thanks for the report.

You wrote: "but I cannot reproduce it again on go1.15.5 either" -- meaning that this is not a repeatable/reproducible crash?

Looking at the failing stack trace, the value passed to "dst" in loader.(*Loader).migrateAttributes is corrupted, which doesn't seem possible. The only things written to the loader's Syms slice are sym.Symbol pointers.

[SamWhited]

You wrote: "but I cannot reproduce it again on go1.15.5 either" -- meaning that this is not a repeatable/reproducible crash?

That's correct, I SSHed into the build VM trying to reproduce it there after I couldn't locally, and now it doesn't seem to be happening anymore. I've only seen it that one time on the linked build.

There is a check that the symbol isn't null right before migrateAttributes is called, so I couldn't see how this would happen either. Never the less, it did, so I thought I'd better report it 🤷

[thanm]

Thanks for confirming. Well, we can just keep an eye out in case something similar happens again.