Multi thread debugging: wrong Paused on Breakpoint label

[dbaeumer]

Tests: #29168

• VSCode Version: 1.14 test pass
• OS Version: Windows

Steps to Reproduce:

1. C# setup as described in Test: Multi threaded delayed call stack fetching #29168
2. Set a breakpoint in one of the threads.
3. The UI shows:

Although the first two threads are not paused.

[dbaeumer]

Actually it looks like that under C# the VM stops. Setting a breakpoint in A and B first hits one breakpoint and when pressing continue the second one is hit. So when the VM is stopped I should be able to inspect that call stacks of all threads.

[isidorn]

@dbaeumer great catch!

[dbaeumer]

Still see it on

Should it be fixed there ? It is the build from last night

[isidorn]

Yeah it shuold be fixed there -> reopening to see if I can also repro with latest

[isidorn]

I just tried with latest insiders and I can not repro both on Win and on Mac.
I think we are using the same sample program so I can only ask you to try again with latest insiders?

I believe the original issue is fixid, so pushing this one to july to see why it is not working for you

[dbaeumer]

I see this on todays insider:

[isidorn]

And when you click on Thread 1 and Thread 2 they can not be expanded?

[dbaeumer]

I see this when expanding:

[isidorn]

@dbaeumer I think that is exected behavior. What would you expect there?
I am not sure what is the issue currently?

[dbaeumer]

@isidorn IMO the thread B is not paused on a breakpoint. Otherwise we would have a stop on line 31. But all threads are labels as "Paused on Breakpoint". Since thread B is actually running the UI should indicate that. To my knowledge a breakpoint in a multi threaded environment can either only stop the thread where the break point is hit or all threads. The UI should indicate that.

[vscodebot]

This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our guidelines for filing issues. Thank you for your contributions.

[dbaeumer]

Reopening issue.

@chrmarti I guess the bot closed the issue since @isidorn owns it and I filed it (both MS employees) and I didn't count as the one providing the needed information.

[chrmarti]

@dbaeumer Correct. Maybe the bot should check if the creator is from the team and in that case leave the bug open. It's not clear though if that will improve things overall.

[isidorn]

This is coming from the debug adapter. VS Code will show the stopped reason per thread, however the c# debug adapter gives reason "breakpoint" for each stopped thread.
I have filled an issue in the C# extension here dotnet/vscode-csharp#1667

[gregg-miskelly]

@isidorn I don't understand what you are expecting the extension to return. The debug adapter just sends one stopped event and uses "allThreadsStopped": true. I think the suggestion in this issue would be in this case to use a more generic reason for the other threads.

Here is an example stopped event from the C# debug adapter:

{
  "seq": 27,
  "type": "event",
  "event": "stopped",
  "body": {
    "reason": "breakpoint",
    "threadId": 21448,
    "allThreadsStopped": true,
    "source": {
      "name": "Program.cs",
      "path": "d:\\proj\\cliasynctest\\Program.cs"
    },
    "line": 11,
    "column": 14
  }
}

[isidorn]

@gregg-miskelly yes you are right, the issue comes from the vscode side when we are cloning the stopped deatils in the allThreadsStopped case here

Thus reopening and setting to august