Ian Lance Taylor <i...@google.com> writes:
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
> both with and without -fsplit-stack support. Committed to mainline.
Once Go bootstrap works again on Solaris, I notice that there are many
64-bit testsuite failures, which have been introduced between 20111125
(r181724) and 20111130 (r181837), so this patch is the obvious culprit.
The failures are as follows:
* In the go.* tests:
FAIL: ./select5-out.go compilation, -O2 -g
WARNING: program timed out.
32-bit compilation on idle system (1.6 GHz Core i7 Q720, so a
reasonably up-to-date system):
./select5-out.go: In function 'main.$init4':
./select5-out.go:19326:1: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
real 2:04.06
user 2:03.43
sys 0.35
with -fno-var-tracking-assignments:
real 1:09.87
user 1:09.57
sys 0.20
With parallel make check, the runtime can easily exceed the default
300s timeout.
* 64-bit failures:
FAIL: go.test/test/chan/doubleselect.go execution, -O2 -g
throw: malloc/free - deadlock
panic during panic
The messages don't show up in go.log, they goes to stdout,
cf. runtime/runtime.h where runtime_printf is just printf.
FAIL: go.test/test/chan/select2.go execution, -O2 -g
BUG: too much memory for 100,000 selects: 2098448
This test used to fail intermittendly, now the failure seems constant.
FAIL: go.test/test/chan/select3.go execution, -O2 -g
throw: gosched of g0
FAIL: go.test/test/fixedbugs/bug147.go execution, -O2 -g
throw: gosched of g0
FAIL: go.test/test/goprint.go execution, -O2 -g
throw: gosched holding locks
sometimes
throw: bad gp->status in sched
FAIL: go.test/test/mallocfin.go execution, -O2 -g
throw: gosched holding locks
FAIL: go.test/test/nil.go execution, -O2 -g
throw: gosched holding locks
FAIL: go.test/test/stack.go execution, -O2 -g
SEGV from a stack overflow, this test seems to require split-stack
support and doesn't even work with unlimited stack size.
* libgo testsuite failures:
All tests hang with the default -test.timeout=240. When I remove
that, some (like bufio) simply pass, while others run into errors
similar to the above:
goroutine 2 has status 1
throw: bad g->status in ready
I've tried to make some sense of it, but don't really know where to
start looking.
The situation on Solaris/SPARC is considerably worse (large number of
32-bit failures, too, all 32-bit libgo tests fail), but I think it's
preferable to get it working again on x86 before checking what remains
on SPARC.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
