This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug go/59433] [4.9 regression] Many 64-bit Go tests SEGV on Solaris
- From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 09 Jan 2014 12:50:24 +0000
- Subject: [Bug go/59433] [4.9 regression] Many 64-bit Go tests SEGV on Solaris
- Auto-submitted: auto-generated
- References: <bug-59433-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
> Should be fixed now.
I'm seeing a massive improvement, but now some 32-bit tests that used to
work before are failing:
Running target unix
+FAIL: net
FAIL: runtime
-FAIL: os/user
+FAIL: log/syslog
+FAIL: net/http
FAIL: sync/atomic
The net failure is another instance of PR go/59431, which I still need
to analyse, but the log/syslog and net/http failures are different.
They both SEGV like this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 3 (LWP 3)]
0xfe0f8a9f in runtime_netpoll (block=block@entry=1 '\001')
at /vol/gcc/src/hg/trunk/local/libgo/runtime/netpoll_select.c:163
163 __builtin_memcpy(prfds, &fds, sizeof fds);
(gdb) where
#0 0xfe0f8a9f in runtime_netpoll (block=block@entry=1 '\001')
at /vol/gcc/src/hg/trunk/local/libgo/runtime/netpoll_select.c:163
#1 0xfe0fd0ef in findrunnable ()
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:1653
#2 schedule () at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:1751
#3 0xfe0fd38a in runtime_mstart (mp=0x18511800)
at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:1000
#4 0xfdd462fc in _thrp_setup () from /lib/libc.so.1
#5 0xfdd465a0 in ?? () from /lib/libc.so.1
#6 0x00000000 in ?? ()
(gdb) p prfds
$1 = (fd_set *) 0x0
(gdb) p fds
$2 = {fds_bits = {352, 0 <repeats 31 times>}}
I suspect they are related to PR go/59431, too: this should only happen
if runtime_SysAlloc returned NULL, which only happens for unhandled mmap
return value, although I don't see that in truss. Need to investigate
in more detail.
Rainer