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: PE linker segfaults in addpersrc when cross-compiling #42384

Open
derekparker opened this issue Nov 5, 2020 · 7 comments
Open

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

derekparker opened this issue Nov 5, 2020 · 7 comments

Comments

@derekparker
Copy link
Contributor

@derekparker derekparker commented Nov 5, 2020

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?

  1. Be on linux
  2. Clone github.com/openshift/origin
  3. 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)

derekparker pushed a commit to derekparker/go that referenced this issue Nov 5, 2020
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
Copy link
Contributor Author

@derekparker derekparker commented Nov 5, 2020

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

@derekparker
Copy link
Contributor Author

@derekparker derekparker commented Nov 5, 2020

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

@ianlancetaylor ianlancetaylor commented Nov 5, 2020

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Nov 5, 2020

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.

derekparker pushed a commit to derekparker/go that referenced this issue Nov 5, 2020
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
Copy link
Contributor Author

@derekparker derekparker commented Nov 5, 2020

@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
Copy link
Contributor

@cherrymui cherrymui commented Nov 5, 2020

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

@cherrymui 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 cherrymui added this to the Go1.15.5 milestone Nov 5, 2020
derekparker pushed a commit to derekparker/go that referenced this issue Nov 6, 2020
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 added a commit to derekparker/go that referenced this issue Nov 6, 2020
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
Copy link

@gopherbot gopherbot commented Nov 6, 2020

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

@cagedmantis cagedmantis modified the milestones: Go1.15.5, Go1.15.6 Nov 12, 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
5 participants
You can’t perform that action at this time.