Expected treatment of threads in debug viewlet UI? about vscode HOT 14 CLOSED

Yes, this is a bug on the VSCode side. The issue seems to be that we only show the thread in the call stack once a stopped event has happened for that thread.

I can fix the issue but it requires testing so I propose to do it after connect event.

from vscode.

After investigating this a bit further, I have some more questions:

• Do you send a 'thread' event (with the reason 'started') once a new thread gets created in your adapter. This event notifies VSCode that there is a new thread and in the mono case I can see new threads even though no breakpoints got hit on those threads
• The current implemenation will only call the stackTrace request for the stopped thread, not for all the threads, which I believe is correct behavior. If you stop on Thread A I do not think it is necessery to check the state of thread B, since you have to report first that something changed in B

Let me know what you think

from vscode.

Assigning to @lukehoban so he reads my comment

from vscode.

Sorry - missed your reply earlier.

Do you send a 'thread' event (with the reason 'started') once a new thread gets created in your adapter. This event notifies VSCode that there is a new thread and in the mono case I can see new threads even though no breakpoints got hit on those threads

No, I don't do this yet, and that is likely the root problem. I see how this is done in the Mono debugger and that makes sense.

Unfortunately, this won't map as easily to the Go debugger as it does in the Mono case. The Delve debugger does not provide any events, only host-initiated RPC commands. I think that's reasonably common for a class of debuggers primarily used through a command line interface.

So to implement this, we will need to get all the threads and compute which are new or stopped to send the events. It feels like the vscode debugger could just be doing that itself since we already provide the ability to list threads.

Is there any reason why you need these events vs. just computing the threads to show based on the ThreadsRequest, just as you do for scopes and variables today (I don't need to fire an event to tell you that the scope changed or that new variables were introduced to a scope)?

The current implemenation will only call the stackTrace request for the stopped thread, not for all the threads, which I believe is correct behavior. If you stop on Thread A I do not think it is necessery to check the state of thread B, since you have to report first that something changed in B

Okay - that makes sense. I think I was just confused because I was seeing multiple threads show stack traces at once in some cases - but probably that was because of not sending the right thread events.

from vscode.

Yes I could do something like you proposed.
@weinand what is your take on this. Should we change how we handle threads in the protocol so we support more adapters?

from vscode.

What I am seeing, is that upon hitting a breakpoint, the adaptor must report all threads in the process as stopped, otherwise vscode seems to think they are still running and won't display their callstacks.
Which may be fine, if you are planning to support something like gdb's 'non-stop' mode, but I feel this behavior could be better documented, 'cause I had to discover it via trial and error.

from vscode.

Oh, and if I report stops for all threads, the debugger UI seems to select which one to display as current randomly, which can lead to confusion as to which thread has caused the stop.
I've tried varying the order in which StoppedEvent's are sent, but that doesn't seem to change anything.

from vscode.

@vadimcn thanks for the feedback! We are aware of some of the issues you mentioned. Currently we are looking into improving/fixing issues around our thread architecture and this will probably be improved for our January release. Will keep you updated.

from vscode.

Any updates? The next release is nigh, but I am still seeing the same issues with threads display.

from vscode.

Unfortunately, this has not been tackled for January. We will look into improving our thread model in our February release.
Sorry about this.

from vscode.

@vadimcn

Oh, and if I report stops for all threads, the debugger UI seems to select which one to display as current randomly, which can lead to confusion as to which thread has caused the stop.
I've tried varying the order in which StoppedEvent's are sent, but that doesn't seem to change anything.

Yes, I'm finding the same issue with my debugger extension. It's making multi-threaded debugging painful with the UI jumping to different sources on each break.

FWIW, I would prefer it if StoppedEvent could take an array of { threadId, reason } entries and use the first as the callstack display priority.

from vscode.

And it would be nice if the threads display prioritised stopped threads over running threads in the order it displays them. I'm finding that on a lot of occasions, the thread that has stopped is the last created thread - which puts it at the bottom of the list requiring the user to scroll down to it.

from vscode.

@adelphes, I have not seen this issue for many months. VSCode displays the correct thread as long as you pass its id in the stop event.

from vscode.

Closing as this issue is ancient, let's keep the discussion here #19858

from vscode.