cmd/link: segv on openshift binary for ppc64le with split text section #18218
Comments
|
CL https://golang.org/cl/34069 mentions this issue. |
ceseo
added a commit
to powertechpreview/go
that referenced
this issue
Dec 7, 2016
While processing a symbol for a function, if it is determined that a function would make the text section too large then a new text section is created and the address of the function is in the new text section. But the symbol for the function is marked as being in the previous text section, causing incorrect codegen for the function and leading to a segv if that function is called. This adds code to set the sym.Sect field to the new section if a new one is created. Note that this problem only happens at the point where a new section is created. Fixes golang#18218 Change-Id: Ic21ae11368d9d88ff6d5d3977f9ea72fe6477ed1 Reviewed-on: https://go-review.googlesource.com/34069 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Backport of 6623988 by Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go1.8beta1
What operating system and processor architecture are you using (
go env)?Ubuntu 16.04
What did you do?
Built openshift with golang 1.8beta1, tried to run it
What did you expect to see?
Successful run
What did you see instead?
Lots of output starting with this:
./_output/local/bin/linux/ppc64le/openshift version
unexpected fault address 0x16d90000
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x16d90000 pc=0x10058408]
goroutine 1 [running]:
runtime.throw(0x139a1e01, 0x5)
/usr/local/go/src/runtime/panic.go:596 +0x7c fp=0xc4204159b8 sp=0xc420415988
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:276 +0x24c fp=0xc420415a18 sp=0xc4204159b8
runtime.memmove(0xc420ccc00a, 0x133f5560, 0x138a1a00)
/usr/local/go/src/runtime/memmove_ppc64x.s:56 +0x78 fp=0xc420415a38 sp=0xc420415a38
runtime.concatstrings(0x0, 0xc420415b58, 0x3, 0x3, 0x9, 0x139acce2)
/usr/local/go/src/runtime/string.go:48 +0x150 fp=0xc420415ae0 sp=0xc420415a38
runtime.concatstring3(0x0, 0x139acce2, 0x9, 0x1399ece0, 0x1, 0x133f5560, 0x138a1a00, 0x1399ece0, 0xc4206b9709)
/usr/local/go/src/runtime/string.go:59 +0x40 fp=0xc420415b30 sp=0xc420415ae0
github.com/openshift/origin/vendor/github.com/spf13/cobra.(*Command).CommandPath(0x3fff800d4028, 0x0, 0x0)
/root/os1_ws/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/vendor/github.com/spf13/cobra/command.go:856 +0x94 fp=0xc420415bb0 sp=0xc420415b30
github.com/openshift/origin/vendor/github.com/spf13/cobra.(*Command).AddCommand(0xc4207766c0, 0xc420415d78, 0x1, 0x1)
/root/os1_ws/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/vendor/github.com/spf13/cobra/command.go:783 +0xa0 fp=0xc420415c68 sp=0xc420415bb0
github.com/openshift/origin/pkg/cmd/openshift.NewCommandOpenShift(0x139acce2, 0x9, 0xc400000001)
/root/os1_ws/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift/openshift.go:118 +0x398 fp=0xc420415e78 sp=0xc420415c68
github.com/openshift/origin/pkg/cmd/openshift.CommandFor(0x3fffde68f653, 0x9, 0x3fffde68f653)
/root/os1_ws/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift/openshift.go:92 +0x1d8 fp=0xc420415f18 sp=0xc420415e78
main.main()
/root/os1_ws/src/github.com/openshift/origin/_output/local/go/src/github.com/openshift/origin/cmd/openshift/openshift.go:32 +0x140 fp=0xc420415f58 sp=0xc420415f18
runtime.main()
/usr/local/go/src/runtime/proc.go:185 +0x200 fp=0xc420415fc0 sp=0xc420415f58
runtime.goexit()
/usr/local/go/src/runtime/asm_ppc64x.s:1271 +0x4 fp=0xc420415fc0 sp=0xc420415fc0
This happens when the text section has been split due to its size and the failure occurs when calling the first symbol in a new section. This symbol has been incorrectly marked as belonging to the previous section. I need to do more testing but I have a simple fix that solves the reported problem.
The text was updated successfully, but these errors were encountered: