Per discussion in #4494 and
https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/hfEHWJKnHls, it's hard
to observe infinite recursion call in go. It's quite painful to find out root cause in a
large code base at least for me.
My suggestion is to introduce an env variable called GOMAXRECURSIONS to set a hard limit
on depth of recursion call. Once the limit is hit, panic the running goroutine. User
should be able to change its value at runtime, just like GOMAXPROCS.
The default limit can be a very large number, e.g. max int64, or just reuse current
strategy (no limit) to avoid any potential performance regression.
This variable should be designed for DEBUG purpose. Users can choose to set it in debug
version and unset it in product version. Or just set it when product version sucks up
abnormal cpu and memory without any clue. So, even if setting this variable will cause a
program 50% slower, it's still acceptable to me.
FYI: I don't think there would any scenario requires unlimit recursion call depth. It
would be great if go complier or vet or runtime could DETECT such infinite recursion and
show error/panic goroutine. Such detection logic would be quite risky (too smart,
maybe), so I wouldn't suggest to implement it. But I guess this is what I truly want...
The text was updated successfully, but these errors were encountered:
I propose that we introduce in package runtime/debug:
// SetMaxStack sets the maximum amount of memory that
// can be used by a single goroutine stack.
// If any goroutine reaches this limit, the program crashes.
// Reducing the maximum only limits future stack growth.
// SetMaxStack returns the previous setting.
// The initial setting is 1 GB.
// SetMaxStack is useful mainly for limiting the damage done by
// goroutines that enter an infinite recursion.
func SetMaxStack(bytes int64) int64