On Wed, Jan 10, 2018 at 3:44 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > >>> the patch broke Solaris bootstrap: >>> >>> mv: cannot stat 'os/signal/internal/pty.s-gox.tmp': No such file or >>> directory >>> make[4]: *** [Makefile:3348: os/signal/internal/pty.s-gox] Error 1 >>> make[4]: *** Waiting for unfinished jobs.... >>> >>> Fixed trivially as follows, which allowed the build to complete. make >>> check still running... >> >> Thanks. Patch committed. > > thanks. Testing has now concluded as well. x86 results are good (no > regressions except for cmd/internal/buildid which fails on Linux, too), > as are 64-bit sparc results. However, 32-bit sparc shows lots of > execution failures: > > * There's > > FAIL: go.go-torture/execute/chan-1.go execution, -O0 > > at all optimization levels, with > > fatal error: all goroutines are asleep - deadlock! > > goroutine 1 [chan send]: > main.main > > /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.go-torture/execute/chan-1.go:5 > > * but the vast majority of failures are like > > FAIL: go.test/test/blank.go execution, -O2 -g > > panic: runtime error: invalid memory address or nil pointer dereference > [signal SIGSEGV: segmentation violation code=1 addr=44 pc=4259573728] > > goroutine 1 [running]: > panic > /vol/gcc/src/hg/trunk/local/libgo/go/runtime/panic.go:554 > unicode..import > /vol/gcc/src/hg/trunk/local/libgo/go/unicode/tables.go:15 > > Thread 2 received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 1)] > runtime.makemap ( > t=t@entry=0xfef645b0 <__go_td_MN6_string__pN18_unicode.RangeTable>, > hint=0, h=0x24) > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/hashmap.go:329 > 329 h.hash0 = fastrand() > > => 0xfead76bc <runtime.makemap+96>: st %o0, [ %i2 + 8 ] > (gdb) p $i2 > $1 = 36 > > (gdb) where > #0 runtime.makemap ( > t=t@entry=0xfef645b0 <__go_td_MN6_string__pN18_unicode.RangeTable>, > hint=0, h=0x24) > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/hashmap.go:329 > #1 0xfe63efe0 in __go_construct_map ( > type=type@entry=0xfef645b0 <__go_td_MN6_string__pN18_unicode.RangeTable>, > count=count@entry=36, entry_size=entry_size@entry=12, > val_offset=val_offset@entry=8, ventries=ventries@entry=0x105815f4) > at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-construct-map.c:32 > #2 0xfeb87b34 in unicode..import () > at /vol/gcc/src/hg/trunk/local/libgo/go/unicode/tables.go:15 > #3 0x00014984 in main.init () > at /vol/gcc/src/hg/trunk/local/gcc/testsuite/go.test/test/blank.go:9 > #4 0xfeac3960 in runtime.main () > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/proc.go:205 > #5 0xfeac1734 in runtime.kickoff () > at /vol/gcc/src/hg/trunk/local/libgo/go/runtime/proc.go:1157 > #6 0xfda8b24c in __makecontext_v2 () from /lib/libc.so.1
Whoops, there's a bug on big-endian 32-bit systems. I'm testing https://golang.org/cl/87135. Ian
