x/playground: no error reported when program gets stuck

[adonovan]

This program gets stuck in an endless function recursion: https://go.dev/play/p/6NKY1ZpmDV9:

func g() {
	g()
}

func main() {
	println("start")
	g() // expect to see "stack overflow" or perhaps "killed by timeout". Nope
	println("end")
}

but the playground simply reports "Program exited". It should either print "timeout running program" or print a stack trace if it ran out of stack. (Running on gotipplay reports "exited: status 137", which to cognoscenti means 128 + SIGKILL, which is better but still cryptic.)

Contrast with this program which gets stuck in a simple loop https://go.dev/play/p/Oq1QfpRiGk_5. It does report "timeout running program":

func main() {
	println("start")
	for {
	}
	println("end")
}

[prattmic]

Huh, I've never even heard of gotipplay. It seems slightly different than https://go.dev/play/p/6NKY1ZpmDV9?v=gotip, which has the same result as Go 1.18.

My best guess is that the process is getting killed by the OS before it gives a nice panic and we aren't handling that case well (by printing the exit code for example), but I'm not sure how to check that.

cc @findleyr @toothrot

[cherrymui]

Running the program alone (outside of playground), it fails relatively quickly with stack overflow error. I wonder why that is not the case in playground. Perhaps playground has a rather small memory limit so it OOM-killed before the runtime's stack limit is reached?

https://go.dev/play/p/ly2AtpQZYae?v=gotip also gets no print.

[findleyr]

Huh, I've never even heard of gotipplay. It seems slightly different than https://go.dev/play/p/6NKY1ZpmDV9?v=gotip, which has the same result as Go 1.18.

go.dev calls gotipplay as its backend when v=gotip. This is how multiple versions are supported from the frontend.