IntelliSense sometimes hangs forever in v1.19.9

[rokostrup]

Environment

• OS and Version: 5.15.133.1-microsoft-standard-WSL2 on W11 Pro (Build 22631). WSL runs Ubuntu 22.04
• VS Code Version: 1.87.2 on x86
• C/C++ Extension Version: v1.19.7
• If using SSH remote, specify OS of remote machine: Using WSL + Ubuntu 22.04

Bug Summary and Steps to Reproduce

Bug Summary: Starting VS Code on a fairly large project (build folder has been excluded with: "files.exclude": { "build/**": true, ...}). I use CMake Tools in combination with the project (using it as a configuration provider).

After a while, saving starts to take a long time and the IntelliSense stops working. If there was a red squiggle in the code it remains, even after the error has been resolved.

Restarting VS Code helps resolve the issue, but then it starts happening again. It usually happens within 5-30 minutes. It's wildly annoying since it constantly breaks my workflow.

It seems to be worsened by adding FormatOnSave, but this is only a gut feeling.

Tried to roll back to v1.18.5, which seems to have fixed the issue. Everything else remains the same, so it looks like the issue was introduced between those two versions. I haven't tried to do a binary search for when the bug was introduced.

Side Question Are parsing of files still excluded when the CMake Tools is the configuration provider? It looked like some of the files under my build dir where still being parsed (when setting Logging Level -> Debug).

Configuration and Logs

{
    "configurations": [
        {
            "name": "Linux",
            "compilerPath": "/usr/bin/gcc",
            "cStandard": "c17",
            "cppStandard": "c++20",
            "intelliSenseMode": "linux-gcc-x64",
            "configurationProvider": "ms-vscode.cmake-tools"
        },
        {
            "name": "Win32",
            "cStandard": "c17",
            "cppStandard": "c++20",
            "intelliSenseMode": "windows-msvc-x64",
            "configurationProvider": "ms-vscode.cmake-tools"
        }
    ],
    "version": 4
}

Other Extensions

CMake Tools v1.17.17.

Additional context

No response

[sean-mcmanus]

Yes, this was already reported in https://github.com/microsoft/vscode-cpptools/issues/12051 and we've reproed and fixed the issue in our pending 1.19.8 release which we're planning to release later today.

[rokostrup]

@sean-mcmanus , just tried out the new release (v1.19.8) and it was running good for a while (2 hours), but just had the issue again -> IntelliSense seems to be hanging forever.

[sean-mcmanus]

@rokostrup We could use more info. Is any CPU being used by cpptools or cpptool-srv? Can you set C_Cpp.loggingLevel to "Debug" and provide the C/C++ logging starting with the last time an IntelliSense message was invoked but no response was sent? e.g. hover, documentHighlight, etc. (but not documentSymbol or willSaveWaitUntil, which aren't blocked by IntelliSense processing). The callstacks of cpptools and/or cpptool-srv could help, but we don't currently know how you would be able to provide them due the binaries being built with musl on Linux unless you reproed the issue on another OS (https://github.com/microsoft/vscode-cpptools/issues/12091).

Also, does using kill -9 <pid> with the pid of the cpptools-srv process that is stuck cause the extension to start working or is it still stuck (having only 1 file open would make it easier to identify the correct pid). That would help us determine which process is deadlocked.

[sean-mcmanus]

@rokostrup We're not aware of any bugs with excludes not working with configuration providers. It would be better to track that with a separate issue with more repro details.

[rokostrup]

@sean-mcmanus , once it happens again I'll get you some more info and try out the above. Can I set the logging level after I see the error, or should it be on before?

[sean-mcmanus]

@rokostrup You would need to set the loggingLevel to "Debug" beforehand -- I don't believe the logging should slow down the extension.

[rokostrup]

@sean-mcmanus , Thanks. I'll enable it and let you know. It seems to have been running stable for at least 8 hours now, so might be a fluke. I'll close this issue for now and re-open if I see the issue again.

[sean-mcmanus]

@rokostrup I hit a deadlock with 1.19.8 on Linux -- it was after doing a go to definition after an IntelliSense update was triggered on a file. Deadlock is in cpptools-srv (killing the process caused cpptools to continue functioning).

[rokostrup]

@sean-mcmanus thanks for letting me (us) know. Is this something that you plan to fix in the next update?

[sean-mcmanus]

@rokostrup We plan to as soon as we find a fix. We're still investigating.

[rokostrup]

Sounds good. And thanks for a superb tool!

[sean-mcmanus]

@rokostrup This might be fixed with 1.19.9 if it was related to the crashes we fixed -- we haven't reproed the deadlock with that version yet. If it still repros, we should be able to get a call stack with 1.20.0 once we fix https://github.com/microsoft/vscode-cpptools/issues/12091 .

[JohnW71]

I'm still having the issue on 1.19.9, though it was fine for several hours. VS Code 1.87.2 Windows 10. Hopefully 1.20 holds the cure :)

[sean-mcmanus]

@JohnW71 1.20.0 won't (or isn't expected to) have the fix, but it should enable attaching a debugger to get a call stack so we can determine where it's deadlocked.

[sean-mcmanus]

@JohnW71 Also, we're not sure if the issue you're hitting is the same issue the original poster and I hit on Linux. If you set C_Cpp.loggingLevel to "Debug" and see that IntelliSense-based messages like referenceHighlight/hover stop being invoked and killing the IntelliSense cpptools-srv processes fixes the issue, then it's the same issue (deadlock in cpptools-srv). Otherwise, it would be a different issue. It's possible the debug logging leading up to the issue could help without having a call stack of cpptools.exe/cpptools-srv.exe, which currently don't have pdbs available publicly unless you're a Microsoft internal.

[sean-mcmanus]

@JohnW71 Windows x64 symbols for cpptools.exe/cpptools-srv.exe have just been published for 1.19.9, so if you repro bug again and attach a debugger with a launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(Windows) Attach",
            "type": "cppvsdbg",
            "request": "attach",
            "symbolSearchPath": "https://msdl.microsoft.com/download/symbols"
        }

    ]
}

then you could get the call stacks of the threads that appear to be doing work, but are deadlocked. I would try cpptools-srv.exe first. You can ignore the threads that appear to be idle. There probably should only be 2-3 threads that are not idle with 2 of them being deadlocked and maybe some other additional threads stuck as well.

VS has the ability to copy all the call stacks at once, but VS Code seems to only allow copying one thread's call stack at a time.

(Linux call stacks still won't be available till 1.20.0).

[JohnW71]

@JohnW71 Windows x64 symbols for cpptools.exe/cpptools-srv.exe have just been published for 1.19.9, so if you repro bug again and attach a debugger with a launch.json

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(Windows) Attach",
            "type": "cppvsdbg",
            "request": "attach",
            "symbolSearchPath": "https://msdl.microsoft.com/download/symbols"
        }

    ]
}

then you could get the call stacks of the threads that appear to be doing work, but are deadlocked. I would try cpptools-srv.exe first. You can ignore the threads that appear to be idle. There probably should only be 2-3 threads that are not idle with 2 of them being deadlocked and maybe some other additional threads stuck as well.

VS has the ability to copy all the call stacks at once, but VS Code seems to only allow copying one thread's call stack at a time.

(Linux call stacks still won't be available till 1.20.0).

Many thanks for the info, I'll set this up tonight and hope to catch something useful.

[github-actions[bot]]

Hey @sean-mcmanus, this issue might need further attention.

@rokostrup, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[github-actions[bot]]

This issue has been closed because it needs more information and has not had recent activity.