This is a common rookie mistake:

package main

import "fmt"

type A int

func (a A) String() string {
    return fmt.Sprintf("%v", a)
}

func main() {
    var a A
    fmt.Println("this will never print", a)
}

This programs has a cycle calling String(), so it tries to allocate infinite memory and
then gets killed by the kernel. The language is behaving as expected, but debugging this
can be quite tricky. If this happens in a rarely executed section of code, finding what
triggered it is very hard (assuming you don't immediately connect the dots and start
searching for possible sources of unintended recursion). Even getting heap profile is
extremely hard in these circumstances.

Other than hoping that programmers aren't as stupid as me, I wonder if we could make the
program crash with a nicer panic that identifies the bogus recursion, before the kernel
OOM killer sends a SIGKILL.

In Go it's possible[1] to allocate up to 128GB of RAM, so just using a fixed limit for
this wouldn't work.

I guess next time I could tweak the MaxMem constant in malloc.h and try to run the
program again, to get a go-generated panic.

But even better would be Jan Merci's suggestion of having cycle detection in the fmt
package itself. That would probably catch the most common cases.

[1] https://code.google.com/p/go/source/detail?r=a310cb32c278