http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
I've found what's going on: when I look at the failing bufio test, gdb
prints
gdb) p rfds
Cannot access memory at address 0xfffffd7ffe0f9f00
With pmap, I see the following mappings:
FFFFFD7FFDE00000 2048K rw--- [ anon ]
FFFFFD7FFE101000 4K rw--R [ stack tid=2 ]
FFFFFD7FFE110000 64K rw--- [ anon ]
I.e. the thread stack starts off with just 4 kB, but rfds is 0x7100
bytes from the top of the stack, way beyond the initial allocation and
thus unmapped.
Each fd_set is 8 kB for 64-bit, so the stack consumption in
netpoll_select.c (runtime_netpoll) is way out of bounds.
As a quick hack, I've increased the initial stack size to StackMin:
diff --git a/libgo/runtime/proc.c b/libgo/runtime/proc.c
--- a/libgo/runtime/proc.c
+++ b/libgo/runtime/proc.c
@@ -185,7 +185,7 @@ runtime_newosproc(M *mp)
if(pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED) != 0)
runtime_throw("pthread_attr_setdetachstate");
- stacksize = PTHREAD_STACK_MIN;
+ stacksize = StackMin /* PTHREAD_STACK_MIN */;
// With glibc before version 2.16 the static TLS size is taken
// out of the stack size, and we get an error or a crash if
which lets all but os/user PASS on i386-pc-solaris2.10 and
sparc-sun-solaris2.11.
Rainer
