IntelliSense sometimes hangs forever in v1.19.9 about vscode-cpptools HOT 19 CLOSED

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

from vscode-cpptools.

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

from vscode-cpptools.

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

from vscode-cpptools.

Yes, this was already reported in #12051 and we've reproed and fixed the issue in our pending 1.19.8 release which we're planning to release later today.

from vscode-cpptools.

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

from vscode-cpptools.

@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 #12091 .

from vscode-cpptools.

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

from vscode-cpptools.

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

from vscode-cpptools.

@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 (#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.

from vscode-cpptools.

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

from vscode-cpptools.

@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?

from vscode-cpptools.

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

from vscode-cpptools.

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

from vscode-cpptools.

Sounds good. And thanks for a superb tool!

from vscode-cpptools.

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 :)

from vscode-cpptools.

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

from vscode-cpptools.

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

from vscode-cpptools.

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.

from vscode-cpptools.

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

from vscode-cpptools.