Issue 1:
This bug is about cmd/go returning a useful error message when an invalid GOOS/GOARCH pair is used.

See confusion in #11908.

Related request in #12270 (if we fix this bug, we should probably fix both, using the same source of truth)

Issue 2:
by myannikos:

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. run the attached program (schedtest.go)

What is the expected output?

"suffixarray done" after a few minutes, normal termination after 1h

What do you see instead?

---

panic: 4m21.822623s*** last run took 22.669666ss

goroutine 4 [running]:
main.handler()
/home/mjy/svn/morework/gh/trunk/go/gh/schedtest.go:42 +0x159
created by main.main
/home/mjy/svn/morework/gh/trunk/go/gh/schedtest.go:49 +0x23

goroutine 1 [sleep]:
time.Sleep(0x34630b8a000, 0x40d134)
/usr/local/go/src/pkg/runtime/ztime_amd64.c:21 +0x49
main.main()
/home/mjy/svn/morework/gh/trunk/go/gh/schedtest.go:50 +0x38

goroutine 2 [syscall]:
created by runtime.main
/usr/local/go/src/pkg/runtime/proc.c:221

goroutine 3 [running]:
index/suffixarray.(*suffixSortable).updateGroups(0xf84002d7c0, 0xf80861e33f,
0xf84002d7c0, 0xf84002d780)
/usr/local/go/src/pkg/index/suffixarray/qsufsort.go:150 +0xf4
index/suffixarray.qsufsort(0x255f3f0, 0xbebc2000bebc200, 0x0, 0x0, 0x0, ...)
/usr/local/go/src/pkg/index/suffixarray/qsufsort.go:58 +0x28a
index/suffixarray.New(0x255f3f0, 0xbebc2000bebc200, 0x0, 0xbebc200, 0x1, ...)
/usr/local/go/src/pkg/index/suffixarray/suffixarray.go:36 +0x36
main._func_001()
/home/mjy/svn/morework/gh/trunk/go/gh/schedtest.go:29 +0x5e
created by main.initÂ·1
/home/mjy/svn/morework/gh/trunk/go/gh/schedtest.go:31 +0xa9

goroutine 5 [syscall]:
created by addtimer
/usr/local/go/src/pkg/runtime/ztime_amd64.c:72

---

This can be reproduced every time (tested on 3 different hosts with different hardware
[8-48 cores] several times).

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

Debian Squeeze x86-64

Which version are you using? (run 'go version')

1.0.3

Please provide any additional information below.

Despite GOMAXPROCS(40), this program uses fewer threads usually (but not 1). Attaching
gdb to the program during a freeze showed that all but the thread executing the
suffixarray goroutine were in runtime.futex (nextgandundlock() =>
runtimeÂ·notesleep(&m->havenextg) => ...), so it seems that the scheduler
simply decided to ignore the stalled goroutine for a while.

(gdb) info threads
Id Target Id Frame
* 6 Thread 0x7fe3087d7700 (LWP 4188) 0x0000000000410dbc in nextgandunlock ()
at /usr/local/go/src/pkg/runtime/proc.c:635
5 Thread 0x7fe30779e700 (LWP 4189) runtime.futex ()
at /usr/local/go/src/pkg/runtime/sys_linux_amd64.s:238
4 Thread 0x7fe306f9d700 (LWP 4196) runtime.futex ()
at /usr/local/go/src/pkg/runtime/sys_linux_amd64.s:238
3 Thread 0x7fe30679c700 (LWP 4197) runtime.futex ()
at /usr/local/go/src/pkg/runtime/sys_linux_amd64.s:238
2 Thread 0x7fe305f9b700 (LWP 4198) runtime.futex ()
at /usr/local/go/src/pkg/runtime/sys_linux_amd64.s:238
1 Thread 0x7fe3090bb700 (LWP 4187) 0x00000000004d8b95 in sort.doPivot (
data="(*suffixarray.suffixSortable)0xf87c9f9c40", lo=208, hi=400, midlo=
400, midhi=0) at /usr/local/go/src/pkg/sort/sort.go:132

The systems were sometimes slightly busy and others not, the panic still happens always
after around 4 minutes (possibly directly related to CPU speed; 2200-2400 MHz Opterons
take ~4m10s-4m20s, a 2500 MHz Xeon L5420 took 6m40s to panic with 35s freeze) and until
then 1 core/thread is 100% busy as expected. I'm confident this isn't an OS issue
(sync/bdflush or other periodic tasks), but unsure whether this is related to the
specific workload (index/suffixarray) or not, or perhaps to garbage collection incurred
by the workload.

It is noteworthy that the stalled/frozen goroutine (the one calling panic()) seems to be
scheduled normally most of the time (can be verified by printing a timestamp at every
iteration), i.e. it does not stall frequently for smaller periods of time, there are
just a few very long freezes.

This issue was discovered while working a net/http handler with background
initialization using index/suffixarray, the http requests would sometimes take more than
1 minute to get serviced for no apparent reason (normal time < 1s), so this is a
critical issue for us.

Attachments:

schedtest.go (909 bytes)