cmd/link: PE linker segfaults in addpersrc when cross-compiling #42384

derekparker · 2020-11-05T00:04:22Z

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

$ go version
 go version go1.15.3 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/deparker/.cache/go-build"
GOENV="/home/deparker/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/deparker/Code/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/deparker/Code/gopath"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/home/deparker/Code/GolangOpenSSL/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/deparker/Code/GolangOpenSSL/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build620928098=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Be on linux
Clone github.com/openshift/origin
Run make build-cross

What did you expect to see?

Successful compilation

What did you see instead?

# github.com/openshift/origin/cmd/oc
unexpected fault address 0x7f4f9c3c8008
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x7f4f9c3c8008 pc=0x5ef04e]

goroutine 1 [running]:
runtime.throw(0x6cf29c, 0x5)
        /home/deparker/Code/GolangOpenSSL/go/src/runtime/panic.go:1116 +0x72 fp=0xc00288ed40 sp=0xc00288ed10 pc=0x436512
runtime.sigpanic()
        /home/deparker/Code/GolangOpenSSL/go/src/runtime/signal_unix.go:749 +0x405 fp=0xc00288ed70 sp=0xc00288ed40 pc=0x44cc05
cmd/link/internal/ld.addpersrc(0xc000075880)
        /home/deparker/Code/GolangOpenSSL/go/src/cmd/link/internal/ld/pe.go:1495 +0x16e fp=0xc00288ede0 sp=0xc00288ed70 pc=0x5ef04e
cmd/link/internal/ld.Asmbpe(0xc000075880)
        /home/deparker/Code/GolangOpenSSL/go/src/cmd/link/internal/ld/pe.go:1569 +0x245 fp=0xc00288ee48 sp=0xc00288ede0 pc=0x5ef3e5
cmd/link/internal/amd64.asmb2(0xc000075880)                                                            
        /home/deparker/Code/GolangOpenSSL/go/src/cmd/link/internal/amd64/asm.go:842 +0xfa fp=0xc00288eeb8 sp=0xc00288ee48 pc=0x60d9fa                                                                         
cmd/link/internal/ld.Main(0x872840, 0x20, 0x20, 0x1, 0x7, 0x10, 0x0, 0x0, 0x6dab5f, 0x1b, ...)         
        /home/deparker/Code/GolangOpenSSL/go/src/cmd/link/internal/ld/main.go:349 +0x1509 fp=0xc00288f118 sp=0xc00288eeb8 pc=0x5e2a69                                                                         
main.main()                                                                                            
        /home/deparker/Code/GolangOpenSSL/go/src/cmd/link/main.go:68 +0x1dc fp=0xc00288ff88 sp=0xc00288f118 pc=0x65e13c                                                                                       
runtime.main()                                                                                         
        /home/deparker/Code/GolangOpenSSL/go/src/runtime/proc.go:204 +0x209 fp=0xc00288ffe0 sp=0xc00288ff88 pc=0x438d09                                                                                       
runtime.goexit()                                                                                       
        /home/deparker/Code/GolangOpenSSL/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc00288ffe8 sp=0xc00288ffe0 pc=0x46b161

(Ignore the path of the Go source, this reproduces with the Go binaries available for download. The copy I have is built from release-1.15 so I could test changes)

The text was updated successfully, but these errors were encountered:

When `rsrc.P` is used directly, the array backing the byte slice seems to be at a very odd area in memory which causes the code to later segfault when assigning to the slice (see associated issue for segfault address). This change fixes it so that the linker no longer segfaults when accessing the slice. Fixes golang#42384

derekparker · 2020-11-05T00:14:02Z

Hmm, this actually seems like it may be fixed in master, but is broken in the release-go1.15 branch.

derekparker · 2020-11-05T00:19:12Z

I have a patch which seems to fix things in Go 1.15 (the one GitHub is referencing above). I'd be happy to submit a PR which can be cherry-picked into that release if appropriate.

ianlancetaylor · 2020-11-05T01:15:57Z

CC @thanm @cherrymui

cherrymui · 2020-11-05T02:17:58Z

Thanks for the report.

Is the resource symbol written to the binary in another place other than the .rsrc section? If that happens, I could see a problem, as rsrcsym.P may point to memory we already unmapped.

But I don't understand why the patch above would work. At that point we have cleared many fields from the loader, so I wouldn't expect loader.Data to work.

Maybe we could, if rsrcsym exists, copy rsrcsym.P to heap at the beginning of Asmbpe and let rsrcsym.P point to the heap copy. That probably will work.

When `rsrc.P` is used directly, the array backing the byte slice seems to be at a very odd area in memory which causes the code to later segfault when assigning to the slice (see associated issue for segfault address). This change fixes it so that the linker no longer segfaults when accessing the slice by copying the data to the heap instead of relying on the original data to not have been munmapped underneath us. Fixes golang#42384

derekparker · 2020-11-05T16:13:13Z

@cherrymui thanks for the feedback! Would something like derekparker@220805b be closer to what you have in mind? I've tested it locally and it does indeed fix the segfault.

cherrymui · 2020-11-05T23:31:40Z

@derekparker yes, that is what I thought of. Thanks. (Maybe add a comment explaining the reason when you send a CL.)

When `rsrc.P` is used directly, the array backing the byte slice seems to be at a very odd area in memory which causes the code to later segfault when assigning to the slice (see associated issue for segfault address). This change fixes it so that the linker no longer segfaults when accessing the slice by copying the data to the heap instead of relying on the original data to not have been munmapped underneath us. Fixes golang#42384

gopherbot · 2020-11-06T18:45:41Z

Change https://golang.org/cl/268018 mentions this issue: cmd/link/internal/ld/pe: Fix segfault adding resource section

cagedmantis · 2020-12-02T19:43:41Z

@derekparker Would you be able to confirm that this issue doesn't exist in go1.14 as well.

derekparker · 2020-12-02T22:41:00Z

@cagedmantis that's correct, I've tested with 1.14.12 which does not exhibit this issue.

cagedmantis · 2021-01-14T23:20:50Z

Approved as this is a serious issue without a known workaround.

gopherbot · 2021-02-02T22:17:06Z

Closed by merging aa9b48c to release-branch.go1.15.

…resource section The resource symbol may have been copied to the mmap'd output buffer. If so, certain conditions can cause that mmap'd output buffer to be munmap'd before we get a chance to use it. To avoid any issues we copy the data to the heap when the resource symbol exists. Fixes #42384 Change-Id: I32ef5420802d7313a3d965b8badfbcfb9f0fba4a GitHub-Last-Rev: 7b0f430 GitHub-Pull-Request: #42427 Reviewed-on: https://go-review.googlesource.com/c/go/+/268018 Run-TryBot: Carlos Amedee <carlos@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Trust: Carlos Amedee <carlos@golang.org>

cherrymui changed the title ~~PE linker segfaults in addpersrc when cross-compiling~~ cmd/link: PE linker segfaults in addpersrc when cross-compiling Nov 5, 2020

cherrymui added this to the Go1.15.5 milestone Nov 5, 2020

cherrymui added the CherryPickCandidate Used during the release process for point releases label Nov 5, 2020

derekparker mentioned this issue Nov 6, 2020

[release-branch.go1.15] cmd/link/internal/ld/pe: fix segfault adding resource section #42427

Closed

cagedmantis modified the milestones: Go1.15.5, Go1.15.6 Nov 12, 2020

cagedmantis modified the milestones: Go1.15.6, Go1.15.7 Dec 3, 2020

cagedmantis added the CherryPickApproved Used during the release process for point releases label Jan 14, 2021

gopherbot removed the CherryPickCandidate Used during the release process for point releases label Jan 14, 2021

dmitshur modified the milestones: Go1.15.7, Go1.15.8 Jan 19, 2021

gopherbot closed this as completed Feb 2, 2021

golang locked and limited conversation to collaborators Feb 2, 2022

gopherbot added the FrozenDueToAge label Feb 2, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/link: PE linker segfaults in addpersrc when cross-compiling #42384

cmd/link: PE linker segfaults in addpersrc when cross-compiling #42384

derekparker commented Nov 5, 2020

derekparker commented Nov 5, 2020

derekparker commented Nov 5, 2020

ianlancetaylor commented Nov 5, 2020

cherrymui commented Nov 5, 2020

derekparker commented Nov 5, 2020

cherrymui commented Nov 5, 2020

gopherbot commented Nov 6, 2020

cagedmantis commented Dec 2, 2020

derekparker commented Dec 2, 2020

cagedmantis commented Jan 14, 2021

gopherbot commented Feb 2, 2021

cmd/link: PE linker segfaults in addpersrc when cross-compiling #42384

cmd/link: PE linker segfaults in addpersrc when cross-compiling #42384

Comments

derekparker commented Nov 5, 2020

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

derekparker commented Nov 5, 2020

derekparker commented Nov 5, 2020

ianlancetaylor commented Nov 5, 2020

cherrymui commented Nov 5, 2020

derekparker commented Nov 5, 2020

cherrymui commented Nov 5, 2020

gopherbot commented Nov 6, 2020

cagedmantis commented Dec 2, 2020

derekparker commented Dec 2, 2020

cagedmantis commented Jan 14, 2021

gopherbot commented Feb 2, 2021

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

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