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

[av4625]

Environment

• OS and Version: MacOS 12.7.3
• VS Code Version: 1.87.0
• C/C++ Extension Version: 1.19.4
• If using SSH remote, specify OS of remote machine: N/A

Bug Summary and Steps to Reproduce

Bug Summary:
Just while using VS code everything will be working as normal then ever so often I just get the IntelliSense: Updating spinning wheel and it never stops. Sometimes it will keep errors in the "Problems" pain even after they are fixed when this happens and I have to Quit VS code and restart. Then it will work for a while and do it again. I build the code with the CMake pluggin incase that makes a difference.

Steps to reproduce:
Don't have to be doing anything special, it just happens on normal use.

One way to make it happen quite reliably is to close the MacBooks lid and let it sleep while VS code is open, open it again and usually I will get the constant updating spinning wheel until VS code is quit and restarted.

Another way to make it happen quite reliably is have VS code open on one desktop and slide to another, then slide back to the VS code desktop again and usually I will get the constant updating spinning wheel until VS code is quit and restarted.

Expected behavior:
For the spinning wheel to go stop after a period and the intellisense to work.

Configuration and Logs

{
    "version": 4,
    "configurations": [
        {
            "name": "Mac",
            "compilerPath": "/usr/bin/clang",
            "compilerArgs": [],
            "intelliSenseMode": "clang-x64",
            "includePath": [
                "${workspaceFolder}/**",
                "${workspaceFolder}/../build/version",
                "/my-home/.conan/data/gtest/1.12.1/_/_/package/bea8f6d16a8dc05432bcc6dc8e49989621426e7e/include/",
                "/my-home/.conan/data/boost/1.81.0/_/_/package/5aa37845b0c4f80d5fc678ca5c4995018b9ada03/include/",
                "/my-home/.conan/data/nlohmann_json/3.11.2/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/",
                "/my-home/.conan/data/sqlitecpp/3.3.1/_/_/package/d8c13d601fc0940cfc263caf4a804f499b164c06/include/",
                "/my-build-location/_deps/http_server-src/include/"
            ],
            "forcedInclude": [],
            "cStandard": "c17",
            "cppStandard": "c++17",
            "defines": [
                "USBCON",
                "MAC"
            ]
        }
    ]
}


```JSON
{
  "os": "darwin",
  "vscodeVersion": "1.87.0",
  "cmtVersion": "1.17.17",
  "configurations": [
    {
      "folder": "/my-home/race_data_logger",
      "cmakeVersion": "3.27.3",
      "configured": true,
      "generator": "Unix Makefiles",
      "usesPresets": false,
      "compilers": {
        "C": "/usr/bin/clang",
        "CXX": "/usr/bin/clang++"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug"
    ],
    "requests": [],
    "responses": [],
    "partialMatches": [],
    "targetCount": 82,
    "executablesCount": 21,
    "librariesCount": 32,
    "targets": []
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": false
    }
  ]
}

LSP: (received) textDocument/completion: file:///my-src-dir/race_data_logger/test/unit/posix/hal/storage/database_tests.cpp (id: 346)
LSP: $/cancelRequest (textDocument/completion, id: 346)
LSP: (received) cpptools/getCodeActions: file:///my-src-dir/race_data_logger/test/unit/posix/hal/storage/database_tests.cpp (id: 347)
LSP: (received) cpptools/getDocumentSymbols: file:///my-src-dir/race_data_logger/test/unit/posix/hal/storage/database_tests.cpp (id: 348)
LSP: (invoked) cpptools/getDocumentSymbols: file:///my-src-dir/race_data_logger/test/unit/posix/hal/storage/database_tests.cpp (id: 348)
LSP: Sending response (id: 348)

I this while waiting for code completion to show. I get pretty much identical logs if I try and hover over something, it just says loading for ever.

### Other Extensions

* Arduino
* Atom one dark theme
* C/C++
* Cmake
* Cmake tools
* Git blame
* Github actions
* Go
* Isort
* Jupyter
* Jupyter cell tags
* Jupyter key map
* Jupyter notebook renderers
* Jupyter slideshow
* Pylance
* Python
* Python debugger
* Serial monitor
* Trailing spaces
* vscode-pets
* vscode-stl-viewer

### Additional context

After downgrading to 1.18.5 I don't have any issues.

[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.

[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

[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).

[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.