Comment 1:

Program (2) is just an infinite loop, so it probably consumed too much CPU.  That's a
valid failure.
Program (1) is weirder.  I got:
runtime: memory allocated by OS (0xfe390000) not in usable range [0x10300000,0x90300000)
runtime: out of memory: cannot allocate 10485760-byte block (2140143616 in use)
fatal error: out of memory
goroutine 1 [running]:
runtime.throw(0x828d7, 0xa00)
    /tmp/sandbox/go/src/pkg/runtime/panic.c:471 +0xa0 fp=0xfeee1e70
runtime.mallocgc(0xa00000, 0x52481, 0x1, 0x1)
    /tmp/sandbox/go/src/pkg/runtime/malloc.goc:91 +0x560 fp=0xfeee1eb8
cnew(0x52480, 0xa00000, 0x1, 0x678e)
    /tmp/sandbox/go/src/pkg/runtime/malloc.goc:715 +0x120 fp=0xfeee1ed0
runtime.cnewarray(0x52480, 0xa00000)
    /tmp/sandbox/go/src/pkg/runtime/malloc.goc:728 +0x60 fp=0xfeee1ee8
makeslice1(0x51a40, 0xa00000, 0xa00000, 0xfeee1f38)
    /tmp/sandbox/go/src/pkg/runtime/slice.goc:54 +0x60 fp=0xfeee1ef8
runtime.makeslice(0x51a40, 0x8832a2c0, 0xa00000, 0x0, 0xa00000, ...)
    /tmp/sandbox/go/src/pkg/runtime/slice.goc:35 +0xe0 fp=0xfeee1f20
main.(*Foo).SendMessage(0x1031a000, 0x678e)
    /tmpfs/gosandbox-b43bb864_aca893ba_481f18a4_7e41ebab_34f9f204/prog.go:23 +0xe0 fp=0xfeee1f58
main.main()
    /tmpfs/gosandbox-b43bb864_aca893ba_481f18a4_7e41ebab_34f9f204/prog.go:33 +0xc0 fp=0xfeee1f80
runtime.main()
    /tmp/sandbox/go/src/pkg/runtime/proc.c:220 +0x1c0 fp=0xfeee1fc0
runtime.goexit()
    /tmp/sandbox/go/src/pkg/runtime/proc.c:1394 fp=0xfeee1fc8

Owner changed to @rsc.

Status changed to Accepted.

Comment 2:

Actually, I bet the playground just doesn't even GC.
But perhaps we can make the error messages in the playground for both (1) and (2) be
better: "Code used too much CPU for the playground" and "Code allocated too much memory
for the playground".

Comment 3:

Well, I messed up the second link. Should be (from discussion group):
1. http://play.golang.org/p/PTxGY_fgvj
2. http://play.golang.org/p/2kHpSfC05T (which does not cause OOM)
On my local machine with latest go1.2rc4 memory is not released for (1), but is for (2).

Comment 4:

Still, it's just an infinite loop.  It blew its CPU budget.

Owner changed to ---.

Comment 5:

> Still, it's just an infinite loop.  It blew its CPU budget.
Yes, that is correct. That is expected, and I would expect the same for (1). (2) should
probably not even be mentioned here to avoid any confusion, it just shows that a small
code change in (2) compared to (1) causes OOE (instead of "process took too long" which
is expected). Problem occurs in (1) only.

Comment 6:

I've noticed the change in the topic "playground: GC issue". This was *not* reported as
playground issue. Playground is used just so that I don't C&P entire code here. 
This is GC issue happening on my env, I can see GC not releasing memory properly for
program 1 (via GODEBUG=gctrace=1) using go1.2rc4.

Comment 7:

The confusion is because "process took too long" is an error from the playground. You
should instead show the error message you are seeing locally.
Either way it's hard to get very excited about a spinning program doing something weird.
Does the issue go away if you do any real work, anywhere in the program?

Status changed to New.

Comment 8:

I confirmed that this happens, and also that it happens even with Go 1.1. This is caused
by a lingering reference to the original foo.messages on the stack, perhaps left by the
creation of the original channel during func main. The problem is that stack frames are
not collected precisely, so garbage like that can be misinterpreted as live. We had
hoped to fix this for Go 1.2, but it was not ready in time. It's on the slate for Go 1.3.

Status changed to Duplicate.

Merged into issue #909.