runtime: go 1.6 (linux/amd64) segfault with musl libc

[cyli]

I am running into a similar issue to #14476 (comment) where the binary I compile using go 1.6 using musl (https://github.com/mattes/migrate, which depends upon https://github.com/mattn/go-sqlite3, which may just have some problematic CGO, but I don't know what to look for) is segfaulting during runtime. To reproduce:

$ docker run -it golang:1.6.0-alpine sh
/go # apk add --update git alpine-sdk
...
/go # go get github.com/mattes/migrate
/go # migrate
Segmentation fault

Here's the version of Go and the env on that image:

/go # go version
go version go1.6 linux/amd64
/go # go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Here are the strace and GDB results:

/go # strace /go/bin/migrate 
execve("/go/bin/migrate", ["/go/bin/migrate"], [/* 14 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fac21441da8) = 0
set_tid_address(0x7fac21441de0)         = 12
mprotect(0x7fac21440000, 4096, PROT_READ) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x55961ac54f00} ---
+++ killed by SIGSEGV +++
Segmentation fault

Output from running gdb /go/bin/migrate:

Reading symbols from /go/bin/migrate...done.
Loading Go Runtime support.
(gdb) r
Starting program: /go/bin/migrate 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d93531 in ?? () from /lib/ld-musl-x86_64.so.1
(gdb) bt
#0  0x00007ffff7d93531 in ?? () from /lib/ld-musl-x86_64.so.1
#1  0x0000000000000000 in ?? ()
(gdb) quit

The 1.6.0-alpine image is based on alpine3.3. In case you wanted to use the ISO to replicate instead, maybe http://wiki.alpinelinux.org/cgi-bin/dl.cgi/v3.3/releases/x86_64/alpine-3.3.1-x86_64.iso will work?

[ncopa]

I think it happens because alpine has a hardenend toolchain that will use PIE by default. We use this patch on Alpine go package:

diff --git a/src/cmd/link/internal/ld/lib.go b/src/cmd/link/internal/ld/lib.go
index 8ccbec9dd634..4e96bfadc260 100644
--- a/src/cmd/link/internal/ld/lib.go
+++ b/src/cmd/link/internal/ld/lib.go
@@ -1194,6 +1194,11 @@ func hostlink() {
        argv = append(argv, peimporteddlls()...)
    }

+   // The Go linker does not currently support building PIE
+   // executables when using the external linker. See:
+   // https://github.com/golang/go/issues/6940
+   argv = append(argv, "-fno-PIC")
+
    if Debug['v'] != 0 {
        fmt.Fprintf(&Bso, "host link:")
        for _, v := range argv {

And i tested the docker image with or without it. The patch is needed.

[tianon]

Has there been a CL to attempt to fix this in a way that doesn't require patching the Go source to hard-code -fno-PIC? 😢

[ncopa]

There is an open issue for that #6940 but it will likely not be implemented for go 1.6. Meanwhile, since go does not support PIE, I´d say it is correct to explicitly disable linking with PIE instead of relying on default behaviour of linker.

[cyli]

@ncopa Sorry for the long time without response - that seems to fix it for me, thanks! Do you think this issue should be closed since #6940 exists and docker-library/golang#91 has been merged?

[bradfitz]

Yeah, I'll close this.