debug - additional steps should not be sent until previous step has completed

[chuckries]

VSCode Version:

Version 1.0.0
Commit fa6d0f03813dfb9df4589c30121e9fcffa8a8ec8
Date 2016-04-13T14:08:36.599Z
Shell 0.35.6
Renderer 45.0.2454.85
Node 4.1.1

It is possible to spam a debug adapter with step or continue requests before previous requests have finished. This can cause multiple issues, including these:

1. The debug adapter is issued a step request while it is already performing a step.
2. Stopped state such as callstack and variables can be requested while the process is running.

Here is a log from the C# debugger of the commands (C) received from VS Code and the Response (R) and Events (E) returned by the debug adapter:

C next: {"threadId":19448}
 R: {"success":true,"message":null,"request_seq":10,"command":"next","body":null,"running":false,"refs":null,"seq":17,"type":"response"}
E stopped: {"threadId":19448,"reason":"step","source":{"name":"Program.cs","path":"c:\\Users\\chuckr\\Source\\scratch\\Program.cs","sourceReference":0},"line":13,"column":17,"text":null,"allThreadsStopped":true,"type":"stopped"}
C stackTrace: {"threadId":19448,"levels":20}
 R: {"success":true,"message":null,"request_seq":11,"command":"stackTrace","body":{"stackFrames":[{"id":1000,"source":{"name":"Program.cs","path":"c:\\Users\\chuckr\\Source\\scratch\\Program.cs","sourceReference":0},"line":13,"column":17,"name":"ConsoleApplication.Program.Main(string[] args)"},{"id":1001,"source":null,"line":0,"column":0,"name":"[External Code]"}]},"running":false,"refs":null,"seq":20,"type":"response"}
C scopes: {"frameId":1000}
 R: {"success":true,"message":null,"request_seq":12,"command":"scopes","body":{"scopes":[{"name":"Locals","variablesReference":1000,"expensive":false}]},"running":false,"refs":null,"seq":21,"type":"response"}
C variables: {"variablesReference":1000}
 R: {"success":true,"message":null,"request_seq":13,"command":"variables","body":{"variables":[{"name":"args","value":"{string[0]} [string[]]","variablesReference":0}]},"running":false,"refs":null,"seq":22,"type":"response"}
C next: {"threadId":19448}
C next: {"threadId":19448}
 R: {"success":true,"message":null,"request_seq":15,"command":"next","body":null,"running":false,"refs":null,"seq":26,"type":"response"}
C next: {"threadId":19448}
 R: {"success":true,"message":null,"request_seq":16,"command":"next","body":null,"running":false,"refs":null,"seq":27,"type":"response"}
E stopped: {"threadId":19448,"reason":"step","source":{"name":"Program.cs","path":"c:\\Users\\chuckr\\Source\\scratch\\Program.cs","sourceReference":0},"line":15,"column":17,"text":null,"allThreadsStopped":true,"type":"stopped"}
C next: {"threadId":19448}
 R: {"success":true,"message":null,"request_seq":17,"command":"next","body":null,"running":false,"refs":null,"seq":30,"type":"response"}
1: (11089) <-1028-stack-list-frames 0 1000 --thread 19448
C next: {"threadId":19448}
E stopped: {"threadId":19448,"reason":"step","source":{"name":"Program.cs","path":"c:\\Users\\chuckr\\Source\\scratch\\Program.cs","sourceReference":0},"line":10,"column":13,"text":null,"allThreadsStopped":true,"type":"stopped"}
 R: {"success":true,"message":null,"request_seq":18,"command":"next","body":null,"running":false,"refs":null,"seq":33,"type":"response"}
C next: {"threadId":19448}

It can easily be seen from this log that additional step commands are sent before stopped events are received for previous steps. I have also seen cases where things appear to happen in this order:

1. Step Command
2. Stopped Event
3. Step Command
4. StackTrace Command

Here the StackTrace command in 4 corresponds to the stopped event from 2, but a new step has already been issued and the process is running, meaning a stacktrace cannot be retrieved.

The UI should prevent sending these step commands until it has received a stopped event rather than relying on each debug adapter to protect themselves from this behavior.

[chuckries]

@weinand

[weinand]

@isidorn since you've removed the workaround for the issue with stopped events overtaking request results, it should now be possible to disable the step action UI until a previous action has finished, right?

[isidorn]

@weinand theoretically yes. If we go into 'continue' mode as soon as we send a step event the step actions will be nicely disabled. However this will also cause the variables tree to clear and that will have tree flickering as a result between step commands. So I have to experiment more with this to see what is the best solution. Clearing the tree with a timeout sounds like a potential solution.

[isidorn]

Now we are immediatly disabling these actions, but only fully transitioning to running after 500ms (to avoid tree flickering). This should not break any behavior, though we should keep our eyes open.

[chuckries]

When will this be in Alpha? I'd like to try it out with our debugAdapter.

[weinand]

@chuckries the commit is already available in the latest OS X alpha build. And I've just started Windows and Linux builds.