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

panicOnError() does not behave properly with context cancellation #59

Closed
AWoloszyn opened this issue Feb 17, 2020 · 8 comments
Closed
Assignees
Labels

Comments

@AWoloszyn
Copy link
Contributor

GAPIS can arbitrarily crash when a context is cancelled, if it happens in some api.go functions.

@pau-baiget
Copy link
Contributor

From @AWoloszyn
This can be reproduced by clicking on a bunch of stuff commands in the UI, and not waiting for them to be done before clicking more. It works best with a large trace. Its also non-deterministic, but DOES happen effectively at random

@pau-baiget
Copy link
Contributor

@silence-do-good this has been open for a while, are you able to work on it?

@silence-do-good
Copy link
Contributor

@silence-do-good this has been open for a while, are you able to work on it?

I haven't been able to get this reproduced on the System Profiler side yet. Was having this bug open in case it occurs, but we can close it for now and reopen if it gets reported again.

@AWoloszyn
Copy link
Contributor Author

This may not happen in the system profiler but is 100% reproducible when looking at a graphics trace.

@pau-baiget
Copy link
Contributor

Without a good reproduction case, it's difficult to act on it soon. Will keep this open as P2 so we can work on it in the next bug-hunt iteration.

@pau-baiget pau-baiget added P2 and removed P1 labels Jun 12, 2020
@AWoloszyn
Copy link
Contributor Author

If you click in the UI faster than the server can respond, this will eventually lead to a crash.

@AWoloszyn
Copy link
Contributor Author

To be clear this happens on Vulkan traces. No idea about the systems profiler.

@pau-baiget pau-baiget added P1 and removed P2 labels Jun 18, 2020
hevrard added a commit to hevrard/agi that referenced this issue Nov 30, 2020
If the context gets cancelled during capture command mutation,
panicOnError() may be triggered and leads to a GAPIS panic. This
change catches such panics and transform them to regular errors.

Another option would have been to get rid of panicOnError and
propagate the errors across all generated code inside Mutate
functions: I had a quick try at this, and it gets quite
cumbersome, especially things like:

```
foo := bar(..., MustRead(...), ...)
```

must be turned into:

```
tmp, err := MustRead(...)
if err != nil {
  return nil, err
}
foo := bar(..., tmp, ...)
```

Using panic for control flow is not awesome, but it is very convenient
here to jump from possibly deep-nested calls in generated code up to
the top-level of Mutate.

Fix google#59
Bug: b/149701723
Test: manual, by hard-coding panics and errors
hevrard added a commit to hevrard/agi that referenced this issue Nov 30, 2020
If the context gets cancelled during capture command mutation,
panicOnError() may be triggered and leads to a GAPIS panic. This
change catches such panics and transform them to regular errors.

Another option would have been to get rid of panicOnError and
propagate the errors across all generated code inside Mutate
functions: I had a quick try at this, and it gets quite
cumbersome, especially things like:

```
foo := bar(..., MustRead(...), ...)
```

must be turned into:

```
tmp, err := MustRead(...)
if err != nil {
  return nil, err
}
foo := bar(..., tmp, ...)
```

Using panic for control flow is not awesome, but it is very convenient
here to jump from possibly deep-nested calls in generated code up to
the top-level of Mutate.

Fix google#59
Bug: b/149701723
Test: manual, by hard-coding panics and errors
@hevrard
Copy link
Contributor

hevrard commented Feb 3, 2021

Fixed with #639

@hevrard hevrard closed this as completed Feb 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants