Threads window is not updated after each call to threadsRequest()

[adelphes]

• VSCode Version: 1.9
• OS Version: Linux x64

The threads display is not being correctly updated after a call to threadsRequest().

I'm working on adding multi-threading support to the Android debugging extension and after the initial call, I'm finding that the threads shown in the UI rarely correspond to the return values from the call to threadsRequest(). In particular, newly created threads are not displayed and deleted threads remain even though they are no longer in the ThreadsResponse body.

This may be related to the ongoing thread-handling discussion in #40 but this does appear to be a distinct problem in the current build.

[adelphes]

Digging into this issue, it seems that the threads display is updated correctly if the response to threadsRequest() is completely synchronous. Delaying the response appears to confuse it.

[isidorn]

@adelphes so you are saying that VSCode is sending a threads request to your debug adapter, your debug adapter only responds after some time(what time?) and then vscode ignores your response since the call stack view does not update?

Does call stack view nicely update if you send 'ThreadEvent' instead? Since you can send this event any time you want.

Just to be on the safe side please read how vscode is expecting that the debug adapter is handling threads here

How hard would it be to setup a reproducable sample so we can try this out on our side?

[adelphes]

I've now fixed this issue in my adaptor, so I think it can probably be closed.

I was (asynchronously) retrieving thread information from the Android device on each call to threadsRequest - each request takes a few milliseconds, but it was probably overkill to do it every time. I was getting weird results on breakpoint hits because some threads were still showing in the UI - long after I knew they had exited and tracing threadsRequest() showed they weren't being reported back to VSCode. I assumed the UI would be doing some sort of diff from the results of calls to threadsRequest(), but that was probably a bad assumption.

In any case, I've updated my adaptor to actively monitor thread creation/exit and send the appropriate ThreadEvents (I wasn't doing this before). I also cache the information so I can send the result back immediately from threadsRequest(). I had an additional problem that thread IDs were being reused in the the Java runtime (which I now know VSCode doesn't like).
In the end, it was probably a combination of issues in my adaptor.

[isidorn]

@adelphes got it. Thanks for providing an explanation.

[vadimcn]

@isidorn, so is ThreadEvent mandatory?

I understand that without it, VSCode won't know about newly spawned threads while the program is running. But one has received a stop event, and queried thread list via the threads request, it has the full list, so ThreadEvent shouldn't be necessary?

This used to work (without sending ThreadEvents) for a while, but I've noticed that this is no longer the case (as of v1.15.1). If I don't send a "thread created" event for each new thread, they don't show up in the callstack pane.

[isidorn]

@vadimcn sorry for the slow response I was on vacation.
On every stop event vscode will ask the frontend for all threads here

So you are saying that on a stop event if there was no thread created event that thread will not de displayed? Correct?

[vadimcn]

So you are saying that on a stop event if there was no thread created event that thread will not de displayed? Correct?

Yes, only the threads whose tids were ever mentioned in StoppedEvent are shown in the UI.

This used to be the case a while back, then VSCode was changed to display all threads returned by ThreadsRequest, so I stopped sending ThreadEvents to reduce chatter. But now it seems to be back to old ways again. I can put sending ThreadEvents back, if that's what the spec says.

[isidorn]

"Thread events are optional but a debug adapter can send them to force VS Code to update the threads UI dynamically even when not in a stopped state"
From https://code.visualstudio.com/docs/extensionAPI/api-debugging

So, yes they are optional.

@vadimcn please file a new issue regarding the problem you outlined in the comments above. And mention me on it.
@weinand fyi

[vadimcn]

#33472