IntelliSense stuck at loading...

[AScustomWorks]

Os X 10.12.6

CPUs	Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz (4 x 3500)
Load (avg)	4, 4, 4
Memory (System)	32.00GB (22.11GB free)
Process Argv	/Applications/Visual Studio Code.app/Contents/MacOS/Electron -psn_0_2212380
Screen Reader	no
VM	0%

Extension	Author (truncated)	Version
cpptools	ms-	0.16.1

Go to Definition and go to Declaration do nothing, Peek definition and Peek declaration get stuck on "loading..."

Tried deleting the App and related files, uninstalling/installing cpptools but no luck.

Is there a way to go back to an older version of cpptools?, A couple of days ago everything was working just fine.

[sean-mcmanus]

Your previous version was 0.15.0, right?

Is the Microsoft.VSCode.CPP.Extension.darwin processes crashed, alive with 0% CPU, or alive with CPU usage?

What is your "intelliSenseEngine" setting? Can you try changing it to "Tag Parser" to see if that works?

Also, can you check your Users/<user>/Library/Logs/DiagnosticReports for any resulting crash logs?

What's the most recent .vsix at https://github.com/Microsoft/vscode-cpptools/releases that works for you? You want the "-osx" version.

If anyone else is hitting this, please up vote it so we can get a better understanding of how widespread this regression is.

[AScustomWorks]

1.-
0.15.0, Yes I think so. Since opening this issue I got back to it thru .vsix, really needed to do so as I'm working on a project.

2.-
Microsoft.VSCode.CPP.Extension.darwin and Microsoft.VSCode.CPP.IntelliSense.Msvc.darwin were still running with CPU usage even after closing the app, sometimes 2 or 3 instances of them (had to force quit them on the activity monitor)

3.-
With 0.16.1 I tried both "default" and "Tag Parser" without any luck. I left the app open for a few hours so it could update the database, also the flame icon was always present.

4.-
attached crash file
Code Helper_2018-03-31-230212_iMac5K.crash.zip

5.-
0.15.0 is working fine.

[sean-mcmanus]

The crash file is a crash from VS Code itself and not our extension. It looks like the Microsoft.VSCode.IntelliSense.Msvc.darwin process (red flame) is infinite looping, although setting the intelliSenseEngine to "Tag Parser" should cause that process not to run (no red flame), so in that case Microsoft.VSCode.CPP.Extension.darwin might be getting stuck as well -- the main input thread is probably deadlocked (the CPU usage is most likely from the database icon, which runs independently, assuming the CPU usage goes away when the database icon is finished). Go to Definition will usually fail to work as long as the red flame is showing (IntelliSense parsing blocks it). One thing to try is to make sure your compilerPath is set correctly, or setting it to "" might also be a workaround (assuming the additional compiler includes/defines is causing the issue).

I assume this problem doesn't happen on a simple project, right? It could be an issue with your particular project. One known infinite loop is #1294 .

Are you able to attach a debugger and get a call stack for the stuck processes? Otherwise, we'd need to find a repro on our Mac machines.

[AScustomWorks]

Thanks Sean!
Right, no crash report for the extension itself then.
Not sure about how/where to set compilerPath. I'm using VSC as an editor only, and the included terminal for make commands, that matters?
And yes, 33,789 items on the development folder sounds like more than a simple project. Maybe a lot of files for IntelliSense to process?

Also not sure about how to attach a debugger and get a call stack.

Maybe this info helps?, on c_cpp_propierties.json:

            "name": "Mac",
            "includePath": [
                "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1",
                "/usr/local/include",
                "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/9.0.0/include",
                "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include",
                "/usr/include",
                "${workspaceRoot}",
                "${workspaceRoot}/Rack/include",
                "${workspaceRoot}/Rack/plugins",
                "${workspaceRoot}/Rack/dep/include"
            ],

[sean-mcmanus]

If you do an "Edit Configuration" command you'll see the c_cpp_properties.json file, which should have the compilerPath set to a guessed default path (usually clang on Mac). 33k is a reasonable size that the extension should be able to handle normally. You usually want the system include paths to occur after your project include paths -- we attempt to fix this ordering ourselves (behind the scenes) if the includes queried from the compilerPath match the ones in the includePath.

One thing you could try is setting the loggingLevel to the hidden value of "6" temporarily to see if it shows any errors or strange output (in the C/C++ output window tab).

[AScustomWorks]

Oh, I got back to 0.15.0 so I can't test again 0.16.1 before finishing the current project but I'll do it asap, thanks!.

[bobbrow]

I'm closing old issues marked "more info needed". If you are still having issues with the extension, please ensure you have installed the latest version and open a new issue with the issue details.