-
Notifications
You must be signed in to change notification settings - Fork 67
steppingResumesAllThreads with true results in incorrect thread state in the UI #1530
Comments
We actually disable individual hooks in: The fix for this would be stop sending the notification from Still, it seems a bit weird that we send a single suspend notification and multiple continue notifications no? Is it the case that |
It is weird. VS is the one that needs single suspended event. VSC is more lenient about this. Multiple continued events will definitely break it.
I think the clientid should be enough to manage this behavior. so would not need any additional flags. Also, in this particular case VS will not need this continued event at all. VS UI is perfectly happy with the current state reported by the debugger. Since it always assumes all threads should be running while stepping. So no need to make changes for VS. |
Actually, it seems that It seems this was done to fix #1361 (although I think that the proper fix would be just forwarding the So, the fix I'm thinking about is doing:
What do you think? As a note, I don't know what's the visual studio client id (can you provide it?) |
Actually, I just found the client id in https://microsoft.github.io/debug-adapter-protocol/implementors/tools/ |
Environment data
Actual behavior
Expected behavior
Show show all threads as running in that case.
Steps to reproduce:
t.join()
and step over that line.The text was updated successfully, but these errors were encountered: