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

Jump to bottom

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
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-FreeBSD
Milestone
Unplanned

Comments

@SamWhited
Copy link
Member

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 thanm added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 17, 2020
@thanm
Copy link
Contributor

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 commented Nov 17, 2020 •
edited

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
Contributor

thanm commented Nov 17, 2020

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

@SamWhited SamWhited mentioned this issue Nov 22, 2020
Open
@seankhliao seankhliao added this to the Unplanned milestone Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-FreeBSD
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@SamWhited @seankhliao @thanm