misc/cgo: 1.7rc5 tests segfault on Clear Linux #16618

fenrus75 · 2016-08-05T15:39:10Z

Please answer these questions before submitting your issue. Thanks!

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

1.7rc5

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

root@arjan-box /var/lib/mock/clear-go/root/builddir # go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/golang"
GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Linux OS is Clear Linux (http://www.clearlinux.org)

What did you do?

I'm the distro packager, trying to package 1.7rc5 (in prep for 1.7 release)

What did you expect to see?
What did you see instead?

##### misc/cgo/testcarchive
--- FAIL: TestInstall (0.41s)
        carchive_test.go:130: [gcc -fPIC -m64 -pthread -fmessage-length=0
-fdebug-prefix-map=/tmp/go-build375682752=/tmp/go-build
-gno-record-gcc-switches -I pkg/linux_amd64 -o testp main.c main_unix.c
pkg/linux_amd64/libgo.a]

        carchive_test.go:157:
        carchive_test.go:158: signal: segmentation fault (core dumped)
--- FAIL: TestEarlySignalHandler (0.32s)
        carchive_test.go:232:
        carchive_test.go:233: signal: segmentation fault (core dumped)
--- FAIL: TestSignalForwardingExternal (0.31s)
        carchive_test.go:350: Did not receive OK signal
--- FAIL: TestOsSignal (0.29s)
        carchive_test.go:406:
        carchive_test.go:407: signal: segmentation fault (core dumped)
--- FAIL: TestSigaltstack (0.34s)
        carchive_test.go:438:
        carchive_test.go:439: signal: segmentation fault (core dumped)
FAIL

any suggestions on diagnosing this welcome; it seems coredumps aren't happening really and finding any of the artifacts at the end of the all.bash script is proving hard

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

bradfitz · 2016-08-05T16:06:02Z

Which version of gcc?

/cc @ianlancetaylor

fenrus75 · 2016-08-05T16:07:28Z

gcc 6.1

On Fri, Aug 5, 2016 at 9:07 AM, Brad Fitzpatrick [email protected]
wrote:

Which version of gcc?

/cc @ianlancetaylor https://github.com/ianlancetaylor

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16618 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPeFcTOY0PSL41KoA4T5UpLXaOK_rzDks5qc1-lgaJpZM4Jdzcf
.

fenrus75 · 2016-08-05T16:18:55Z

Steps to reproduce

# run the build env in a docker container
docker run -it clearlinux

# install dev environment
swupd bundle-add os-core-dev go-basic

(one may need a few pathname fixes from https://github.com/clearlinux-pkgs/go due to /etc being only for the sysadmin and not for the OS to fill in)

ianlancetaylor · 2016-08-05T16:45:41Z

The errors you are reporting are in misc/cgo/testcarchive. You can run just those tests by going to that directory and running go test carchive_test.go.

Do you see any other test failures?

fenrus75 · 2016-08-05T16:55:58Z

the go test will run the OS go, not the newly built one (and since the
build fails that won't get installed)

On Fri, Aug 5, 2016 at 9:46 AM, Ian Lance Taylor [email protected]
wrote:

The errors you are reporting are in misc/cgo/testcarchive. You can run
just those tests by going to that directory and running go test
carchive_test.go.

Do you see any other test failures?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16618 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPeFWVLwCe5cfMkPrDAcTE_Pfdbfyz4ks5qc2jxgaJpZM4Jdzcf
.

ianlancetaylor · 2016-08-05T17:25:48Z

I have no idea how this works in Docker.

At the point of that test failure, Go has already been installed and be used independently. Yes, you would have to use the newly installed Go, not the system go.

Do you see any other test failures?

fenrus75 · 2016-08-05T17:34:58Z

I'll poke some more to get better isolation on this

On Fri, Aug 5, 2016 at 10:26 AM, Ian Lance Taylor [email protected]
wrote:

I have no idea how this works in Docker.

At the point of that test failure, Go has already been installed and be
used independently. Yes, you would have to use the newly installed Go, not
the system go.

Do you see any other test failures?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16618 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPeFc8rEQmiSCC-n5WUCHNk45GP27Ilks5qc3JYgaJpZM4Jdzcf
.

fenrus75 · 2016-08-05T21:08:34Z

managed to get the testsuite not delete the test binary...

#0 runtime.raise () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:110
110 RET
Loading Go Runtime support.
(gdb) bt
#0 runtime.raise () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:110
#1 0x0000000000437dd0 in runtime.dieFromSignal (sig=11) at /usr/lib/golang/src/runtime/signal1_unix.go:195
#2 0x0000000000438439 in runtime.sigfwdgo (sig=11, info=0x7ffc6fe29070, ctx=0x7ffc6fe28f40, ~r3=216) at /usr/lib/golang/src/runtime/signal2_unix.go:32
#3 0x000000000043962f in runtime.sigtrampgo (sig=11, info=0x7ffc6fe29070, ctx=0x7ffc6fe28f40) at /usr/lib/golang/src/runtime/signal_sigtramp.go:16
#4 0x0000000000454275 in runtime.sigtramp () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:234
#5 0x0000000000454340 in ?? () at /usr/lib/golang/src/runtime/sys_linux_amd64.s:311
#6 0x0000000000000007 in ?? ()
#7 0x0000000000000000 in ?? ()

ianlancetaylor · 2016-08-05T21:58:46Z

Thanks. That stack trace implies that we received a signal when the runtime package variable signalsOK was false, which implies that it occurred before the Go runtime was initialized. Can you find out what caused the SIGSEGV?

randall77 · 2016-08-05T22:13:02Z

This could be #16590 . Try to patch in the CL from that issue and see if it helps.
@crawshaw

fenrus75 · 2016-08-05T22:16:42Z

I'll poke at the patch in that issue.

Note that running the test app in gdb directly (rather than pointing it at a core dump) leads to a crash in an SSE/AVX instruction in pthreads where it appears the stack is not 16 byte aligned properly (but only 8 byte aligned), while the pthread code assumes it gets called with a properly aligned stack...

who owns aligning the initial stack at startup.. is that a go low level thing or is that even before any go code runs?

fenrus75 · 2016-08-05T22:24:28Z

(gdb) bt
#0 0x00007ffff7fa5f56 in pthread_create () from /usr/lib64/libpthread.so.0
#1 0x0000000000401896 in x_cgo_sys_thread_create (func=, arg=) at /builddir/build/BUILD/go/src/runtime/cgo/gcc_libinit.c:24
#2 0x0000000000453eda in _rt0_amd64_linux_lib () at /usr/lib/golang/src/runtime/rt0_linux_amd64.s:36
#3 0x000000000045811b in __libc_csu_init ()
#4 0x00007ffff7df72b0 in __libc_start_main () from /usr/lib64/libc.so.6
#5 0x000000000040100a in _start () at ../sysdeps/x86_64/start.S:120

minux · 2016-08-05T22:24:52Z

Could you please post the stack trace for the AVX crash? It might be the cause that we're not careful with proper stack alignments on the system stack.

minux · 2016-08-05T22:33:51Z

I see that _rt0_amd64_linux_lib is using a 16-byte aligned stack frame (0x50 bytes). Could you please try break on _rt0_amd64_linux_lib and display the value of %rsp to rule out the possibility that glibc is not passing correctly aligned stack? b *_rt0_amd64_linux_lib r p/x %rsp

fenrus75 · 2016-08-05T22:37:00Z

(gdb) p/x $rsp
$1 = 0x7fffffffe318

fenrus75 · 2016-08-05T22:37:23Z

Dump of assembler code for function _rt0_amd64_linux_lib:
=> 0x0000000000453e80 <+0>: sub $0x50,%rsp
0x0000000000453e84 <+4>: mov %rbp,0x48(%rsp)
0x0000000000453e89 <+9>: lea 0x48(%rsp),%rbp
0x0000000000453e8e <+14>: mov %rbx,0x10(%rsp)
0x0000000000453e93 <+19>: mov %rbp,0x18(%rsp)

minux · 2016-08-05T22:46:09Z

Seems like the dynamic linker is passing non-16-byte-aligned stack pointer to DT_INIT_ARRAY functions?

ianlancetaylor · 2016-08-05T22:47:23Z

No, I think it is our fault. It is normal for the stack to be aligned before the call instruction, and thus at an 8-byte offset at the start of the function.

ianlancetaylor · 2016-08-05T22:50:11Z

Perhaps broken by the change to enable frame pointers by default.

minux · 2016-08-05T22:51:08Z

Ahh, then the solution is simply increase the frame size of _rt0_amd64_linux_lib by 8?

ianlancetaylor · 2016-08-05T22:51:52Z

Ahh, then the solution is simply increase the frame size of _rt0_amd64_linux_lib by 8?

That would be my guess, yes. Why nobody else is seeing this I do not know.

fenrus75 · 2016-08-05T22:52:17Z

as to why others don't see this... clear linux is rather aggressive on the use of sse/avx...

minux · 2016-08-05T22:59:24Z

A more generic fix is harder. Because Go functions don't require special stack alignments, and we certainly don't want to make cmd/internal/obj always align the stack to 16-byte. Perhaps in Go 1.8, we introduce a new textflag to say this function needs extra stack alignment and apply those to all functions that call external code?

minux · 2016-08-05T23:21:22Z

@fenrus75, could you please give https://golang.org/cl/25550 a try?

fenrus75 · 2016-08-05T23:23:50Z

sure testing now

minux · 2016-08-05T23:28:08Z

@ianlancetaylor, I managed to disable the framepointer experiment, and indeed the stack frame size changes. Does Go 1.7 officially support disabling the framepointer experiment with GOEXPERIMENT="noframepointer"? If yes, then we need a better fix for Go 1.7.

fenrus75 · 2016-08-05T23:35:24Z

with that patch

misc/cgo/testcarchive

PASS

and the build completes correctly/succesfully.
so thumbs-up from my side on the patch

ianlancetaylor · 2016-08-05T23:52:41Z

I think people who set GOEXPERIMENT are permitted to fail.

…inux_lib Fixes golang#16618. Change-Id: Iffada12e8672bbdbcf2e787782c497e2c45701b1 Reviewed-on: https://go-review.googlesource.com/25550 Run-TryBot: Minux Ma <[email protected]> Reviewed-by: Arjan Van De Ven <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>

bradfitz changed the title ~~1.7rc5 segfaults in test suite (linux)~~ misc/cgo: 1.7rc5 tests segfault on Clear Linux Aug 5, 2016

bradfitz assigned ianlancetaylor Aug 5, 2016

gopherbot closed this as completed in 26015b9 Aug 5, 2016

golang locked and limited conversation to collaborators Aug 5, 2017

gopherbot added the FrozenDueToAge label Aug 5, 2017

rsc unassigned ianlancetaylor Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

misc/cgo: 1.7rc5 tests segfault on Clear Linux #16618

misc/cgo: 1.7rc5 tests segfault on Clear Linux #16618

fenrus75 commented Aug 5, 2016 •

edited by bradfitz

Loading

bradfitz commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016 •

edited by bradfitz

Loading

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

randall77 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016 •

edited

Loading

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

ianlancetaylor commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

minux commented Aug 5, 2016 via email

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016 •

edited

Loading

ianlancetaylor commented Aug 5, 2016

misc/cgo: 1.7rc5 tests segfault on Clear Linux #16618

misc/cgo: 1.7rc5 tests segfault on Clear Linux #16618

Comments

fenrus75 commented Aug 5, 2016 • edited by bradfitz Loading

bradfitz commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016 • edited by bradfitz Loading

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

randall77 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016 • edited Loading

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

ianlancetaylor commented Aug 5, 2016

ianlancetaylor commented Aug 5, 2016

minux commented Aug 5, 2016 via email

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016

minux commented Aug 5, 2016 via email

fenrus75 commented Aug 5, 2016 • edited Loading

misc/cgo/testcarchive

ianlancetaylor commented Aug 5, 2016

fenrus75 commented Aug 5, 2016 •

edited by bradfitz

Loading

fenrus75 commented Aug 5, 2016 •

edited by bradfitz

Loading

fenrus75 commented Aug 5, 2016 •

edited

Loading

fenrus75 commented Aug 5, 2016 •

edited

Loading