Issue 1:
godoc at goneat.org (an Ubuntu amd64 virtual machine) is exploding frequently with this
error message:

runtime: address space conflict: map() =
throw: runtime: address space conflict

runtime.throw+0x40
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/runtime.c:102
runtime.throw(0x80881a, 0xf84dfe0000)
runtime.SysMap+0x8d
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/linux/mem.c:63
runtime.SysMap(0xf84dfe0000, 0x3b30000, 0xbec22c00bec220,
0xbec23c00bec233)
runtime.MHeap_SysAlloc+0x61
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/malloc.c:257
runtime.MHeap_SysAlloc(0x81f438, 0x3b30000, 0xbec3d600bec3cc,
0xbec44d00bec3e4)
MHeap_Grow+0xa1 /build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/mheap.c:188
MHeap_Grow(0x81f438, 0x3b30, 0x100000000, 0xce0e4200ce0db7)
MHeap_AllocLocked+0x2ba
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/mheap.c:93
MHeap_AllocLocked(0x81f438, 0x3b2d, 0xdd5bf200000000,
0xdd5c1300dd5bfb, 0xdd5c1300dd5c13, ...)
runtime.MHeap_Alloc+0xb9
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/mheap.c:64
runtime.MHeap_Alloc(0x81f438, 0x3b2d, 0x100000000,
0xdd6a4f00dd6a4f, 0xdd6bbb00dd6b5a, ...)
runtime.mallocgc+0x2ca
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/malloc.c:58
runtime.mallocgc(0x3b2c5cc, 0x100000001, 0xecb08200000001,
0x4, 0xecb12e00ecb117, ...)
makeslice1+0x7d /build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/slice.c:44
makeslice1(0x595a30, 0xecb17300ecb173, 0x7f892e9e7ba0,
0xecb17300ecb173, 0xecb17300ecb173, ...)
runtime.makeslice+0x86
/build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/slice.c:24
runtime.makeslice(0x595a30, 0xecb173, 0xecb173, 0x1,
0xecb17300ecb173, ...)
index/suffixarray.initGroups+0x3b
/build/buildd/golang-0~2011.03.07.1/src/pkg/index/suffixarray/qsufsort.go:99
index/suffixarray.initGroups(0xf84a4b0000, 0xecb17300ecb173,
0xf842a00000, 0x11ffe0000ecb173, 0x1, ...)
index/suffixarray.qsufsort+0xfd
/build/buildd/golang-0~2011.03.07.1/src/pkg/index/suffixarray/qsufsort.go:37
index/suffixarray.qsufsort(0xf842a00000, 0x11ffe0000ecb173,
0x58d4a8, 0xf842a00000, 0xf846c5a240, ...)
index/suffixarray.New+0x55
/build/buildd/golang-0~2011.03.07.1/src/pkg/index/suffixarray/suffixarray.go:36
index/suffixarray.New(0xf842a00000, 0x11ffe0000ecb173,
0x11ffe0000ecb173, 0xf844016120, 0x719800007198, ...)
main.NewIndex+0x65d
/build/buildd/golang-0~2011.03.07.1/src/cmd/godoc/index.go:863
main.NewIndex(0xf8402a2c00, 0x1, 0x0, 0x0, 0x0, ...)
main.indexer+0xdf
/build/buildd/golang-0~2011.03.07.1/src/cmd/godoc/godoc.go:1259
main.indexer()
runtime.goexit /build/buildd/golang-0~2011.03.07.1/src/pkg/runtime/proc.c:150
runtime.goexit()

Issue 2:
None of these docs specify the control flow of recover:

http://golang.org/ref/spec#Handling_panics
"manage behavior of a panicking goroutine"
"restoring normal execution"

http://golang.org/pkg/builtin/#recover
"manage behavior of a panicking goroutine"
"restoring normal execution"

http://golang.org/doc/articles/defer_panic_recover.html
"regains control of a panicking goroutine"
"resume normal execution"

Where does normal execution resume? Here are three plausible interpretations:

1) if a statement form panicked, control jumps to the immediately following statement;
if an expression form panicked, the expression evaluates to its zero value.

2) the function that deferred the call to recover returns immediately with the zero
value of its result type.

3) the function that deferred the call to recover returns immediately, with the zero
value of its result type iff the result parameters were unnamed, or as if by a
zero-argument "return" statement otherwise.

The implementation seems to follow #3.