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

cmd/link: unexpected fault address #38999

Closed
alexbilbie opened this issue May 11, 2020 · 3 comments
Closed

cmd/link: unexpected fault address #38999

alexbilbie opened this issue May 11, 2020 · 3 comments

Comments

@alexbilbie
Copy link

@alexbilbie alexbilbie commented May 11, 2020

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

$ go version go1.14.1 darwin/amd64

Does this issue reproduce with the latest release?

I've only been able to cause this once, and not again with the same version of go.

I re-ran the command with no modification to code and it built successfully.

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

go env Output
$ go env

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/alex/Library/Caches/go-build"
GOENV="/Users/alex/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOOS="darwin"
GOPATH="/Users/alex/Code/Gocode"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.14.1/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.14.1/libexec/pkg/tool/darwin_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=/var/folders/f7/fdy6pdlj18n_bxddd67h_6cw0000gp/T/go-build669363145=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Ran go build -v on a codebase I've been working on.

What did you expect to see?

Indication of a successful build.

What did you see instead?

~/Code/Gocode/src/github.com/{redacted}/{redacted} $  go build -v
github.com/{redacted}/{redacted}
# github.com/{redacted}/{redacted}
unexpected fault address 0x1c000bff100
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x1c000bff100 pc=0x11a9126]
goroutine 1 [running]:
runtime.throw(0x12b618c, 0x5)
	/usr/local/Cellar/go/1.14.1/libexec/src/runtime/panic.go:1114 +0x72 fp=0xc007b1f038 sp=0xc007b1f008 pc=0x1032702
runtime.sigpanic()
	/usr/local/Cellar/go/1.14.1/libexec/src/runtime/signal_unix.go:702 +0x3cc fp=0xc007b1f068 sp=0xc007b1f038 pc=0x1048e2c
cmd/link/internal/ld.(*Link).loadlib(0xc000001680)
	/usr/local/Cellar/go/1.14.1/libexec/src/cmd/link/internal/ld/lib.go:518 +0x816 fp=0xc007b1f200 sp=0xc007b1f068 pc=0x11a9126
cmd/link/internal/ld.Main(0x149d4a0, 0x10, 0x20, 0x1, 0x7, 0x10, 0x12c11df, 0x1b, 0x12bd3c5, 0x14, ...)
	/usr/local/Cellar/go/1.14.1/libexec/src/cmd/link/internal/ld/main.go:210 +0xb42 fp=0xc007b1f358 sp=0xc007b1f200 pc=0x11c6892
main.main()
	/usr/local/Cellar/go/1.14.1/libexec/src/cmd/link/main.go:68 +0x1bc fp=0xc007b1ff88 sp=0xc007b1f358 pc=0x123c94c
runtime.main()
	/usr/local/Cellar/go/1.14.1/libexec/src/runtime/proc.go:203 +0x212 fp=0xc007b1ffe0 sp=0xc007b1ff88 pc=0x1034d82
runtime.goexit()
	/usr/local/Cellar/go/1.14.1/libexec/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc007b1ffe8 sp=0xc007b1ffe0 pc=0x10621f1
make: *** [build] Error 2
@agnivade agnivade changed the title SEGFAULT during go build cmd/link: unexpected fault address May 11, 2020
@agnivade agnivade added this to the Go1.15 milestone May 11, 2020
@agnivade
Copy link
Contributor

@agnivade agnivade commented May 11, 2020

@thanm
Copy link
Member

@thanm thanm commented May 11, 2020

From the stack trace, it looks as though the crash is happening at a fairly early point in the run, where the linker is scanning through all loaded symbols and looking for references to symbols that might be defined in a host object file. What it's doing is not an advanced or obscure maneuver-- loops like this (iterating over symbols looking at relocations) are literally all over the place in the linker.

Given that the problem is not reproduceable, I'm not sure there is much we can do here. One thing you might want to rule out is a faulty memory module (you might consider running a DRAM check on the mac you are using).

@alexbilbie
Copy link
Author

@alexbilbie alexbilbie commented May 13, 2020

Thanks for the advice @thanm - it turns out I do have a bad memory module in machine!

I'll close this issue on the assumption that it was a fluke.

@alexbilbie alexbilbie closed this May 13, 2020
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
4 participants
You can’t perform that action at this time.