Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/playground: nondeterministic errors should not be cached #26926

Closed
andybons opened this issue Aug 10, 2018 · 3 comments
Closed

x/playground: nondeterministic errors should not be cached #26926

andybons opened this issue Aug 10, 2018 · 3 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@andybons
Copy link
Member

andybons commented Aug 10, 2018

golang/tour#541 has examples of runtime OOM errors being cached indefinitely. We don’t distinguish between a compile-time error (deterministic) and runtime error like OOM (nondeterministic). Since everything runs on the playground, it's not tour-specific.

@ysmolsky

@andybons andybons added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 10, 2018
@andybons andybons added this to the Unplanned milestone Aug 10, 2018
@ysmolski
Copy link
Member

Can we consider every exit through panic as nondetermenistic or just "fatal error: runtime"?

@andybons
Copy link
Member Author

I wouldn't say every exit through panic should be treated as nondeterministic and not be cached. I think we can look at the bugs linked in the original meta issue (golang/tour#531) and construct a blacklist to look at to determine whether something should not be cached.

@gopherbot
Copy link

Change https://golang.org/cl/130035 mentions this issue: playground: prevent caching out of memory runtime errors

matfax pushed a commit to gofunky/playground that referenced this issue Oct 8, 2018
The existing implementation only prevents code caching if the code has
certain compile-time errors. Code with deterministic runtime errors, such as
out of memory errors, are being cached. This causes errors to be
returned in the Go Tour if a different user's run caused an error.
The cache had to be manually cleared in order to clean out the bad run.
This change prevents code that threw an "out of memory" or a "cannot
allocate memory" error from being cached.

Fixes golang/go#26926

Change-Id: Ib281f3076bc674e7c2f08bf9b5c4be36da22d28e
Reviewed-on: https://go-review.googlesource.com/130035
Reviewed-by: Andrew Bonventre <andybons@golang.org>
@golang golang locked and limited conversation to collaborators Aug 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants