<pre class="notranslate">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()</pre>
<pre class="notranslate">None of these docs specify the control flow of recover:

<a href="http://golang.org/ref/spec#Handling_panics" rel="nofollow">http://golang.org/ref/spec#Handling_panics</a>
  "manage behavior of a panicking goroutine"
  "restoring normal execution"

<a href="http://golang.org/pkg/builtin/#recover" rel="nofollow">http://golang.org/pkg/builtin/#recover</a>
  "manage behavior of a panicking goroutine"
  "restoring normal execution"

<a href="http://golang.org/doc/articles/defer_panic_recover.html" rel="nofollow">http://golang.org/doc/articles/defer_panic_recover.html</a>
  "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.</pre>