Out of memory - meta issue

[bgadrian]

I found a group of similar issues, at the first glance they are random errors (OOM) but they all seems to be "temporarily fixed" when the user changes (anything) in the source code.

I did a pre-investigation in #505 and my guess is that some "invisible" characters were slipped in the html source code which cause the runtime error, and the error dissapear at the first change of the textbox. But my example doesn't replicate the error anymore.

A great help would be if someone with access on production servers can look at the errors log, maybe can make a correlation between the referrs (which tour issues generate the errors), if there is any link (or all of them do, meaning is likely a server issue).

So far I have found the following issues:

#385 moretypes/15
#417 concurrency/1

#482 moretypes/13

#512 concurrency/4
#528 concurrency/4
#519 concurrency/4
#508 concurrency/4

#521 flowcontrol/5
#531 flowcontrol/5
#522 flowcontrol/5
#524 flowcontrol/5
#525 flowcontrol/5

[bgadrian]

Since the compilations are done by the playground, can we get some confirmation from their team/servers?
And one more question, where are the /playground specific issues? Maybe I can find there something related.

I'm curious how to find out if the error occurs in the /tour service or is a response from the /playground.

[syedashrafulla]

I believe https://tour.golang.org/moretypes/8 should be added to the list. The weird part is that if I change line 18 in the tutorial to use "XX" instead of "XXX" the run is successful.

[bgadrian]

Most likely it happens on all pages, but there are not enough reporters. Until someone reads the production error logs we are stuck, I cannot reproduce it on my local machine, probably it has something to do with the runtime env, maybe one of the go leads can help us with it?
poke @andybons

New similar issues:
#579
#577
#578
#581

[andybons]

Will take a look.

These all run on the playground, which caches responses depending on hash of the code. It shouldn't be caching OOMs, though. You can run the playground locally to test in the meantime: https://go.googlesource.com/playground/+/master/README.md

[bgadrian]

If the problem was in playground, my guess is that a lot more issues were reported, being a lot more popular. Based on this logic I think the problem lies on the specific tour services.

[andybons]

When running on App Engine, which tour.golang.org is, all /compile requests are proxied to https://golang.org/compile which hits the playground: https://go.googlesource.com/tools/+/master/playground/common.go#21

Example: https://play.golang.org/p/61WfGtE17MQ (from #581)

[andybons]

Opened golang/go#26926 for this since it’s not tour specific. Thank you for collecting this info for us.