Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Run test/nilptr/arrayindex1.go on Darwin/Snow Leopard
2. Watch test spin forever.
3.

What is the expected output? What do you see instead?

Output is:
SIGBUS: bus error
Faulting address: 0x0
pc: 0x1c4b

main·main+0x4b /Users/dga/go/test/nilptr/arrayindex1.go:30
        main·main()
mainstart+0xf /Users/dga/go/src/pkg/runtime/386/asm.s:81
        mainstart()
goexit /Users/dga/go/src/pkg/runtime/proc.c:135
        goexit()
eax     0x0
ebx     0x16814
ecx     0x20047000
edx     0x1
edi     0x9
esi     0x20047050
ebp     0x0
esp     0x20048fc4
eip     0x1c4b
eflags  0x10246
cs      0x17
fs      0x0
gs      0x3f

at this point, the process does *not* exit;  it keeps spinning.


What is your $GOOS?  $GOARCH?

GOARCH=386
GOOS=darwin

Which revision are you sync'ed to?  (hg log -l 1)

changeset:   4148:b56be100e580
tag:         tip
user:        Rob Pike <r@golang.org>
date:        Wed Nov 18 19:58:32 2009 -0800
summary:     replace custom findByte with bytes.IndexByte


Please provide any additional information below.

This has been happening for a few hg syncs now.

Attaching to the spinning process with gdb shows:

0x000053af in ?? ()
(gdb) info reg
eax            0x1      1
ecx            0xa4d4   42196
edx            0x0      0
ebx            0x1f     31
esp            0x20055ab4       0x20055ab4
ebp            0x0      0x0
esi            0x60     96
edi            0x2      2
eip            0x53af   0x53af
eflags         0x10206  66054
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x0      0
gs             0x1f     31

6nm suggests that the point where it's spinning is inside sigtramp:

    53a3 T sigtramp

During the spinning, activity monitor shows the go process taking half the
CPU and kernel task 0 taking the other half.  I'm not entirely sure how to
interpret that unless it's repeatedly segfaulting.