Every so often I just get the spinning wheel for updating and it never updates and the features stop working about vscode-cpptools

[sean-mcmanus]

@hpesoj Yeah, we fixed some deadlock potential cases in 1.19.7, but (you and) I still hit a deadlock with that version on Linux so we're still looking into this -- the last invoked action appeared to be a hover in my repro, excluding the few actions that are handled in a higher priority thread, and your last action appears to be documentHighlight (another IntelliSense-based operation).

Using kill -9 <pid> with the pid of the cpptools-srv process "fixed" the issue in my repro, so it's not really a deadlock, but it's stuck on the cpptools-srv (IntelliSense) process for some reason.

[sean-mcmanus]

We've found a deadlock in cpptools-srv that we believe should fix this issue (for our pending 1.19.8).

[flipperswitch]

I have been experiencing the same thing. I'm running Windows 11 remote ssh to a Debian Testing VM running on the same machine. I turned on logging and there is no additional helpful input other than when it is working. It will work for a few minutes after restarting VS code or even up to a few hours. I haven't been able to track down what triggers it. When it stops working even the squiggles and error comments will stay the same whether fixed or not and will stay on the same line number regardless if the code it is commenting/squiggling has moved or not. This has been happening to me since the end of last week. I've reinstalled the program as well as my extensions and the problem persists. Reloading the window or trying to force a rescan does not change anything, only closing and re-opening vs code will resolve and then only temporarily.

[flipperswitch]

The last time this happened, it was after the computer had gone into sleep when I was away from my desk (it does not only occur during these times). I managed to catch this error in the developer tools console.

[sean-mcmanus]

@flipperswitch Those errors are with our TypeScript code and we don't believe they're related.

@av4625 We believe there is some deadlock in the cpptools process -- is the cpptools process using 0 CPU during this time? Is anyone able to attach a debugger to get a call stack? https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv

[sean-mcmanus]

@av4625 By "one desktop and slide to another" -- what do you mean by "desktop" -- are you moving it from one monitor to another?

[sean-mcmanus]

@av4625 When you set C_Cpp.loggingLevel to "Debug" what is being shown when you put your machine to sleep? Does it repro when VS Code is in an idle state or does something need to be in progress?

[sean-mcmanus]

@av4625 Is there a certain length of time your machine needs to be asleep for to trigger it?

[av4625]

@av4625 By "one desktop and slide to another" -- what do you mean by "desktop" -- are you moving it from one monitor to another?

https://support.apple.com/en-gb/guide/mac-help/mh14112/mac

This is what I mean about multiple desktops. I have vscode on one and safari on another for example. I think you can do similar on windows as well. Not sure if its the desktop switch causing it or just “leaving” vscode, similar to the mac sleeping maybe

[av4625]

@av4625 When you set C_Cpp.loggingLevel to "Debug" what is being shown when you put your machine to sleep? Does it repro when VS Code is in an idle state or does something need to be in progress?

I can check tomorrow hopefully.

[av4625]

@av4625 Is there a certain length of time your machine needs to be asleep for to trigger it?

Don’t think so, I tried it yesterday by closing the lid and opening shortly after

[sean-mcmanus]

@av4625 Can you look for the last "(invoked)" message that hasn't had a response sent? In the logging you provided, the only invoked message is the documentSymbol request which is responded to, so we believe the deadlock is being triggered by the prior invoked message.

[Colengms]

Hi @av4625 . The getDocumentSymbols request is processed at a higher priority than most other requests. I think you were on the right track, but the issue may be another message (at normal priority) that is getting stuck and not sending a response (invoked, but no response with that ID), stalling the message queue.

Would you be able to get a crash stack from your repro? That would likely point to a specific message handler.

[av4625]

Was busy yesterday and was not able to test, today I upgraded to 1.19.5 again and am struggling to reproduce this again, will keep trying for a little while

[av4625]

@av4625 Can you look for the last "(invoked)" message that hasn't had a response sent? In the logging you provided, the only invoked message is the documentSymbol request which is responded to, so we believe the deadlock is being triggered by the prior invoked message.

I got it to happen again, I can't see which was the las invoked to not get a response. But it is just frozen now again.
log.txt

[kobalicek]

I'm experiencing the same issue. On both macbook pro and on my Linux machine.

This started happening recently, like few days ago at most to me, so I would relate this to an update of the extension. I have everything configured properly (I haven't changed my config for months) and it just stopped working. Intellisense is "loading..." all the time.

It's pretty unusable to be honest. And when I open vscode it works, then out of sudden after some time it stops working and I don't see anything usable in the log. But in my case I don't even need to sleep the machine. If intellisense works it just stops after few minutes of use.

[Colengms]

@sean-mcmanus The last message I see at normal priority that was invoked and likely not responded to was a completionItem/resolve

LSP: (received) completionItem/resolve (id: 448)
LSP: (invoked) completionItem/resolve (id: 448)
LSP: $/cancelRequest (completionItem/resolve, id: 448)
LSP: (received) completionItem/resolve (id: 449)
LSP: $/cancelRequest (completionItem/resolve, id: 449)
LSP: (received) completionItem/resolve (id: 450)
LSP: $/cancelRequest (completionItem/resolve, id: 450)
LSP: (received) completionItem/resolve (id: 451)
LSP: $/cancelRequest (completionItem/resolve, id: 451)

The cancellation request is immediately responded to by the LSP manager, which will then discard a response for that request if attempted. If the issue is a message handler not returning, this seems to be the one. Though, a crash stack would be more conclusive. We could also add a log message when a response is discarded due to having been canceled.

[av4625]

Though, a crash stack would be more conclusive.

I've been running the debugger since and can't get it to happen again, typical, when I made the ticket it happened constantly all the time.

When it gets into deadlock will I just see the callstack in the debugger pane? Or do I have to do something? While its running it doesn't show anything.

[av4625]

Happened while the debugger was attached.

Nothing showed:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(lldb) Attach",
            "type": "cppdbg",
            "request": "attach",
            "processId": "${command:pickProcess}",
            "program": "/Users/me/.vscode/extensions/ms-vscode.cpptools-1.19.5-darwin-x64/bin/cpptools-srv",
            "MIMode": "lldb"
        }
    ]
}

Usage stats while its "stuck":

[sean-mcmanus]

@Colengms Yeah, the deadlock appears to be in the completionItem/resolve handler.

@av4625 You're attaching to cpptools-srv instead of cpptools (cpptools-srv is the IntelliSense process, the issue is most likely with cpptools).

[av4625]

Ahh i thought it was in the intellisense as that is where we see the issues

[sean-mcmanus]

@av4625 Our current hypothesis is the main thread that handles IntelliSense communication is getting deadlocked, so further communication with the IntelliSense process can't happen.

[hpesoj]

My project reliably gets stuck updating intellisense forever as well. I've attached the debug log (filenames redacted) in case it's of any help. Note, I'm using 1.19.7.

cpp-intellisense-hanging.txt

[heartacker]

We've found a deadlock in cpptools-srv that we believe should fix this issue (for our pending 1.19.8).

thanks and quickly:D

[sean-mcmanus]

We fixed one deadlock with 1.19.8, but we got another report in #12097 . Has anyone else hit that yet? If so, details like the OS, a call stacks, or the logging could help. I haven't been able to repro any deadlocks so far.