runtime: detect infinite recursion during stack growth

[i3d]

What steps will reproduce the problem?
This simple code reveals an infinite print loop: 
package main 
import "fmt" 
import "log" 
import "runtime/debug" 
var count = 0 
type foo struct { 
  i int 
} 

func (f foo) String() string { 
  count++ 
  if count > 10 { 
    debug.PrintStack() 
    panic("call stack too large") 
  } 
  return fmt.Sprintf("foo@%p value: %d", f, f.i) 
} 

func main() { 
  f := foo{i: 3} 
  // ok 
  log.Println(fmt.Sprintf("foo@%p value: %d", &f, f.i)) 
  // inf loop 
  log.Printf("foo@%p, value: %d\n", f, f.i) 
} 

If you take out the loop protection in the code, you will end up crashing with no system
memory left.

What is the expected output?
There should be a callstack protection so that the program wouldn't chew up all the
system memories.

What do you see instead?
hang and eat up all the memories.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g, 8g

Which operating system are you using?
Linux 386/amd64

Which revision are you using?  (hg identify)
tip

Please provide any additional information below.

Ian's comment:

I think we should use the depth we are already passing down to catch 
this kind of loop before we eat all of memory.

[robpike]

Comment 1:

The actual bug in fmt is in issue #2555; once it's fixed (soon) the example will no
longer trigger the fault.
This bug is about general protection against infinite recursion and should have a
simpler example attached, perhaps something like
func main() {
  var a [1e6]int64
  _ = a
  main()
}

Status changed to Accepted.

[robpike]

Comment 2:

as advertised, the original program now works fine, but the related problem of detecting
infinite recursion is worth thinking about.

[rsc]

Comment 5:

Labels changed: added go1.1maybe.

[robpike]

Comment 6:

Labels changed: removed go1.1maybe.

[rsc]

Comment 7:

[The time for maybe has passed.]

[rsc]

Comment 8:

Issue #5587 has been merged into this issue.

[rsc]

Comment 9:

Status changed to Duplicate.

Merged into issue #4692.

[rsc]

Comment 10:

This issue was closed by revision 757e0de.

Status changed to Fixed.