Skip to content
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

ld: segfault due to nil pointer on FreeBSD/amd64 #42658

Open
SamWhited opened this issue Nov 17, 2020 · 3 comments
Open

ld: segfault due to nil pointer on FreeBSD/amd64 #42658

SamWhited opened this issue Nov 17, 2020 · 3 comments

Comments

@SamWhited
Copy link
Member

@SamWhited SamWhited commented Nov 17, 2020

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
Copy link
Member

@thanm thanm commented Nov 17, 2020

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
Copy link
Member Author

@SamWhited SamWhited commented Nov 17, 2020

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
Copy link
Member

@thanm thanm commented Nov 17, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants