Debug: continue action is broken when target app has multiple threads

[caslan]

We are seeing this issue with CppTools extension and CSharp extension with VS Code 1.1.0 (stable). It doesn't repro in VS Code 1.0.0.

One repro involving CSharp extension is:
Install VS Code 1.1.0
Install .NET CLI tools and CSharp extension per instructions here: https://github.com/gregg-miskelly/omnisharp-vscode/blob/daily-build-docs/debugger.md
Extract the attached project, do a "dotnet restore" on it
clisample.zip
Open the project folder in VS Code, put a bp in line 22
Start debugging
Hit the bp in line 22 multiple times until you have 2 threads running in the app
Remove the bp
Hit continue

The app continues but the VS Code UI thinks it is still in break mode.

[isidorn]

The continue request from vscode always sends the threadID of the thread that should be continued.
Previously in vscode there was an issue that VSCode would react as if the continue continued all the threads. This has been fixed and due to this you are probably seeing this behavior. More details can be found here #1703 and here #5644 I pinged your team members in the issue so you are aware of the change.

So upon continue the debug adapter should only continue that specific thread, not all threads.
If this is not possible then we need to introduce some sort of capability that the debug adapter can specify to vscode that continue should always continue all the threads. @weinand and me are looking into this.

[MattGertz]

So, the 90% user scenario (I guess) is that all threads should continue. Can we revert to that behavior until a mechanism to support single vs. all is put into place & supported?

[delmyers]

I added this additional comment in #5643:

@isidorn, @jacdavis I think that the understanding of how Visual Studio works here is incorrect. The converse of your statement is actually the case. VS does not support pause/continue one. That is, VS is pause/continue all by default, and the AD7 based debuggers are all this way. For the C# debugger and C++ debugger, I think the request is really that the debugger makes the determination about how it will pause/continue debugging.

@edumunoz tested the original change, and didn't find an issue. Possibly, we missed this specific case, or it is harder to repro in C++ than it is in C#.

[MattGertz]

(Note -- I've looped.NET Core War as a potential release blocker; we haven't assessed yet.)

[jacdavis]

Repost from the other thread.
All Visual Studio debuggers (and any debugger on windows using the win32 debug api) use the Stop All model. That is the native debuggers (visual studio, windbg) and the Clr debugger. That is, when a break event occurs, all threads are stopped by the OS before the debugger ever sees the event. A continue continues all threads in the process.

The only way to get into stop one mode on windows is for a user, to go to the threads window in break mode and pause the one thread they want stopped in break mode and then continue. While it would be nice to support a stop one model, it is not something we have ever received feedback from users as necessary. Doing this automatically would introduces huge changes in the way our debuggers would work since new debug events can now arrive while we're in break mode. This is especially heinous when we are performing function evaluations implicitly like we do in managed code.

What vsdiag wants is this: if the stopping event has all threads stopped set to true, continue all threads on continue. That is the behavior we implemented when we added the new flag to the stopped event that all threads are stopped.

[MattGertz]

Confirmed that this is a blocker for .NET Core scenarios & we will need a quick resolution, please.

[delmyers]

@jacdavis Just making a clarification, you said:

All Visual Studio debuggers (and any debugger on windows using the win32 debug api) use the Stop One

I think you meant:

All Visual Studio debuggers (and any debugger on windows using the win32 debug api) use the Stop All

[jacdavis]

Yes, I edited the text in both threads.

[isidorn]

We have changed the behavior such that the stop one / continue one is a special case for php. This is a temporary workaround, in the future we plan to let adapters specify what model they support.

I have triggered VSCode alpha builds and they should be out of the oven in around 20mins, please verify this fix solves the issue described.

Thanks

[hbenl]

The stop/continue all model breaks the debug adapter for Firefox - I need the stop/continue one model to support debugging WebWorkers. Could you please enable the stop/continue one model for the 'firefox' debug type or, even better, add a way for the debug adapter to specify which model it needs.

[egamma]

@hbenl issue extracted into #6400