service/dap: add throw reason to exception info #2524
Conversation
|
Screen shot of fatal throw reason: |
| @@ -3335,6 +3334,9 @@ func TestFatalThrowBreakpoint(t *testing.T) { | |||
| if se.Body.Reason != "exception" || se.Body.Description != "Paused on fatal error" { | |||
| t.Errorf("\ngot %#v\nwant Reason=\"exception\" Description=\"Paused on fatal error\"", se) | |||
| } | |||
|
|
|||
| // TODO(suzmue): Get the exception info for the thread and check the description | |||
| // includes "all goroutines are asleep - deadlock!". | |||
There was a problem hiding this comment.
You should be able to test this, just gate the assertion on the Go compiler being version 1.14 or 1.15 (which we still test via CI).
There was a problem hiding this comment.
The actual issue that is breaking this test is that the deadlock is not associated with a goroutine ID, so we can't request the exception info. This needs to be fixed too, but makes sense to do separately because we will likely want to add the thread that is running to display the stack trace etc.
There was a problem hiding this comment.
What about _fixtures/fatalerror.go? Does that one result in a selected goroutine, so you have an id linked to a description that you can check?
There was a problem hiding this comment.
I don't see that fixture. I could add a fixture to do a concurrent map read / write and I could test it that way.
There was a problem hiding this comment.
Huh! That's because it was in my local client. I was going to add it at some point, but never did. This is easier than concurrent map operations:
func main() {
var f func()
go f()
}
There was a problem hiding this comment.
Added the fixture and the test
There was a problem hiding this comment.
Sorry again for pointing to something that only I had :) Thank you for adding the test.
About the deadlock case with no thread id. I filed an issue against vscode a while back for displaying stopped reason even with no thread id: microsoft/vscode#124532. They seem to be taking it seriously. Can we think of a related way to associate exception info with a stop that has no thread id?
There was a problem hiding this comment.
The exception info is shown in the source code, so if its not associated with a thread with a stack trace, I think there would need to be a separate UI for it.
| @@ -3335,6 +3334,9 @@ func TestFatalThrowBreakpoint(t *testing.T) { | |||
| if se.Body.Reason != "exception" || se.Body.Description != "Paused on fatal error" { | |||
| t.Errorf("\ngot %#v\nwant Reason=\"exception\" Description=\"Paused on fatal error\"", se) | |||
| } | |||
|
|
|||
| // TODO(suzmue): Get the exception info for the thread and check the description | |||
| // includes "all goroutines are asleep - deadlock!". | |||
There was a problem hiding this comment.
What about _fixtures/fatalerror.go? Does that one result in a selected goroutine, so you have an id linked to a description that you can check?
|
See test failures. |
| @@ -3335,6 +3334,9 @@ func TestFatalThrowBreakpoint(t *testing.T) { | |||
| if se.Body.Reason != "exception" || se.Body.Description != "Paused on fatal error" { | |||
| t.Errorf("\ngot %#v\nwant Reason=\"exception\" Description=\"Paused on fatal error\"", se) | |||
| } | |||
|
|
|||
| // TODO(suzmue): Get the exception info for the thread and check the description | |||
| // includes "all goroutines are asleep - deadlock!". | |||
There was a problem hiding this comment.
Sorry again for pointing to something that only I had :) Thank you for adding the test.
About the deadlock case with no thread id. I filed an issue against vscode a while back for displaying stopped reason even with no thread id: microsoft/vscode#124532. They seem to be taking it seriously. Can we think of a related way to associate exception info with a stop that has no thread id?
|
@suzmue Is this PR ready for @derekparker to take another look for final approval? |
|
DeepSource nag sounds reasonable. Probably a good idea to fix it. |
Yes I think its ready.
This is unrelated to this change, so I will just send a quick follow up PR to fix it. |
We can get the throw reason by looking at the argument "s" in runtime.throw. This is not currently working in Go 1.16 or Go 1.17 (see golang/go#46425), but does work in Go 1.15 and Go 1.14