Vscode-cpptools: Goto Definition/Declaration Not Working

[neilhummus]

• Operating System and version:
  Windows 10 Enterprise, version 1709
• VS Code version and if you are using the Insiders build:
  1.23.0, standard
• C/C++ extension version:
  0.17.0
• Other extensions you installed and if the issue persists after disabling them:
  Issue persists through disablement of all other extansions. (cursor align, gitlens, python, reloaded c/c++, reloaded themes).
• step-by-step instructions to reproduce the issue
  Open c/c++ project
  Select a symbol.
  Use command: goto definition/declaration either using hotkey, command bar, or right click menu
  Expected behavior: cursor jumps to definition/declaration of symbol
  Actual behavior: cursor remains where it is. No visible indication that the command was accepted.
• Any log messages present in the Output window (use "C_Cpp.loggingLevel": "Information" in settings.json)
  There appears to be none.

Just started noticing the behavior today after reloading vscode. Verified on one other developer's machine who had updated to 0.17.0 is seeing the same issue. Developers still on 0.16.1 do not have the same issue. Also tested on a developer's windows 7 machine and has the same issue, only after "reloading" vscode to install the c/c++ 0.17.0 update.

Hovering over functions is also not popping up the window with the function prototype like it used to. Changing the "C_Cpp.intelliSenseEngine" setting from "tag parser" to "Default" and back does not seem to make any noticeable difference.

Installing vscode insiders edition and testing it there with the c/c++ extension being the only installed extension does not seem to fix the issue.

[neilhummus]

I have been able to temporarily work around the issue by downgrading the extension back to 0.16.1:

• Uninstall the c/c++ extension.
• In settings, set "extensions.autoUpdate": false
• Download the 0.16.1 .vsix from here: (download link).
• Use the "Extensions: install from vsix" command to re-install version 0.16.1

[montaguk]

Downgrading seems to have worked for me for now as well.

To add some information: when on 0.17.0, I never seem to get the "fire" icon or the "parsing symbols" icon that I do with version 0.16.1. I have confirmed that the Microsoft.VSCode.CPP.* processes are running (one for each open instance of VSCode). I also don't see any errors or warnings in the VSCode developer console that clearly relates to the C/C++ extensions.

[ZanderPete]

For me this happened because my antivirus was blocking the language server in c:\users\username\.vscode\extensions\ms-vscode.cpptools-0.17.0\bin\

[montaguk]

I don't see any warnings or errors from my malware service with regard to that directory. Unfortunately, I don't have permissions on this machine to modify the excluded directories.

Was there some change in the 0.17.0 release that would cause an antivirus to start blocking the language server executable? See the notes above about it working just fine under 0.16.1 which is also running from the vscode extensions directory.

[ZanderPete]

It worked for me on the revision just before this most recent one. I'm not
in a position to check which that is right now. I'm also unable to change
my exclusions because I'm not the net admin, which makes me think it could
be the same thing.

Although VS code actually told me that it could not run the extension's
intellisense.

On Tue, May 8, 2018, 4:17 PM montaguk [e-mail] wrote:

I don't see any warnings or errors from my malware service with regard to
that directory. Unfortunately, I don't have permissions on this machine to
modify the excluded directories.

Was there some change in the 0.17.0 release that would cause an antivirus
to start blocking the language server executable? See the notes above about
it working just fine under 0.16.1 which is also running from the vscode
extensions directory.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode-cpptools/issues/1960#issuecomment-387528988,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Af8DAxKYB3Ez0wCiZxG1DKRLmfsjd-7uks5twf1MgaJpZM4T3Hvr
.

[neilhummus]

I don't get any warnings/errors from vscode. It just fails completely silently.

[montaguk]

@ZanderPete were you able to work around the issue somehow? Based on your last reply it sounds like the solution wasn't to add an antivirus exclusion.

[bobbrow]

You can install the older version of the extension while we try to figure out what's going on, but you'll need to disable automatic updating of extensions in VS Code or it will just reinstall 0.17.0.

https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.1

[sean-mcmanus]

Let us know if any of the Insiders builds work too:
https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.0-insiders2
https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.0-insiders

[bobbrow]

I'm going to reach out to Symantec and see if they know anything about this. I suspect a massive increase of new binaries suddenly showing up (due to the upgrade process) could look like a virus spreading to them.

[neilhummus]

v0.17.0-insiders seems to work correctly for me.
v0.17.0-insiders2 does not work.

As far as I know, my organization doesn't use Symantec, so if it is the antivirus causing my issues, it's more than just an issue with Symantec's protection.

[montaguk]

I can confirm that v0.17.0-insiders appears to work for me as well (insiders2 does not).

[DavidA2014]

With 0.17.0 on Windows, and intelliSenseMode set to "clang-x64", and with "__USE_GNU" set as a define, I found that "__USE_GNU" was actually undefined when inspecting Linux system header files.

Rolling back to v0.17.0-insiders fixed this issue for me.

[sean-mcmanus]

@DavidA2014 I'm not reproing this (it's a different bug from the crashes I think). What compilerPath are you using: cl, mingw, mingw-64, WSL, Cygwin, clang, gcc-arm, etc.?

UPDATE: Oh, you filed https://github.com/Microsoft/vscode-cpptools/issues/1971 ...but that seems unrelated to this _USE_GNU issue.

[ZanderPete]

@montaguk the antivirus is for sure my problem, because it even tells me that it's blocking the extension. I can't actually add it as an exception because it's a work PC. I put in a request to have it white-listed. We'll see how long that takes...

[sean-mcmanus]

@ZanderPete Yeah, our extension processes shouldn't have any virus-type code, so I'm interested to know what's causing it to be flagged. But it sounds like 0.17.0-insiders or 0.16.1 wasn't flagged. Our binary should be signed by Microsoft on Windows, so maybe Symantec could check the binary for a Microsoft signature in addition to checking the name.

[ZanderPete]

insiders got snagged by the antivirus almost immediately. Insiders2 has worked so far, and it's been 45 minutes.

Nevermind same problem with insides2

[bobbrow]

@ZanderPete what does your c_cpp_properties.json look like? Do you happen to have any non-folder paths listed in your includePath? If you accidentally put a path to a file in there (e.g. C:/include/header.h), the extension will repeatedly crash starting with the first insiders build. If this happens to be the case, you should be able to correct the problem by removing such paths from the configuration. We have a fix for this and a few other crashes that will go out in a patch next week. #1979

[ZanderPete]

@bobbrow I never edited the c_cpp_properties file, I just have the blank schema file. My Symantec has stopped quarantining the executable and intellisense is working now.

[sean-mcmanus]

Has this been fixed with 0.17.1?

[neilhummus]

@sean-mcmanus Not for me. 0.17.1 still shows the same issues as 0.17.0. For the time being, I am still needing to use v0.17.0-insiders or v0.16.1.

[montaguk]

0.17.1 does not appear to fix it for me either. I did notice that the Microsoft.VSCode.CPP.Extension.exe*32 process is running and constantly using 10-15% of the CPU. The RAM size continues to grow at about 100KB/sec, but there is no indication in the VSCode toolbar that any indexing is happening.

When I attempt to locate a symbol, I just get the blue "busy bar" that runs across the top of the editing pane, just below the file tabs. The busy bar seems to run until I restart/reload VSCode.

[bobbrow]

If the extension is still running (i.e. you're not hitting the crash/quarantine issue that @ZanderPete is hitting), can you open TaskManager, right click on the extension process and choose "create dump file" so we can see what is going on? If you send us the dump, we'll take a look: [email protected]

If you are working on a confidential project, you might not be allowed to send us the dump though, so please keep that in mind. We won't hold on to the dump any longer than we need to, but your organization may have rules about your project that we don't want you to unintentionally violate.

[sean-mcmanus]

Also we have symbols for 0.17.0 at https://go.microsoft.com/fwlink/?linkid=874019 if you're on Windows and just want to provide call stacks (assuming you're able to attach before the crash).

[neilhummus]

The dump file I was able to make was too big to attach to an e-mail, but here's the callstack I got with version 0.17.0:

ntdll.dll!_NtReadFile@36
() Unknown
KERNELBASE.dll!772ee1f2() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for KERNELBASE.dll]
Microsoft.VSCode.CPP.Extension.exe!_read_nolock(int fh, void * result_buffer, unsigned int result_buffer_size) Line 563 C++
Microsoft.VSCode.CPP.Extension.exe!_read(int fh, void * buffer, unsigned int buffer_size) Line 393 C++
Microsoft.VSCode.CPP.Extension.exe!common_refill_and_read_nolock(const __crt_stdio_stream stream) Line 146 C++
Microsoft.VSCode.CPP.Extension.exe!_fgetc_nolock(_iobuf * public_stream) Line 23 C++
Microsoft.VSCode.CPP.Extension.exe!fgetc(_iobuf * public_stream) Line 52 C++
Microsoft.VSCode.CPP.Extension.exe!std::_Fgetc(char & _Byte, _iobuf * _File) Line 39 C++
Microsoft.VSCode.CPP.Extension.exe!std::basic_filebuf >::uflow() Line 483 C++
Microsoft.VSCode.CPP.Extension.exe!std::basic_filebuf >::underflow() Line 462 C++
kernel32.dll!76d38654() Unknown
ntdll.dll!__RtlUserThreadStart() Unknown
ntdll.dll!__RtlUserThreadStart@8
() Unknown

[montaguk]

I can't provide the dump file of our project due to confidentiality/NDA concerns. I was attempting to get a stack trace and then things got weird...

I manually rolled back to v0.17.0 via the vsix file to try to get a stack trace, and things all of a sudden started working just fine. I then tried moving to v0.17.1 via the marketplace, but that appears to still be broken. Installing v0.17.1 from vsix is also still broken. But for whatever reason v0.17.0 from vsix is working now.

Any chance you have symbols for v0.17.1?

The only thing I can think that was different was that I let v0.17.0 run for about an hour before killing anything. At this point the memory seemed to have topped out around 65MB, but CPU usage was still hovering around 15%.

Also note, that the VSCode.CPP.Extension.exe*32 process does not appear to be crashing per-say, more like a hang/infinite loop situation. Process continues to run indefinitely at 15% cpu. On v0.17.1, the memory usage stops growing at roughly 2K.

[bobbrow]

@neilhummus, can you send us the stacks from the other threads as well? Unfortunately the main thread doesn't have anything of interest in it. It just reads messages from vscode and farms them out to other threads to process.

[neilhummus]

@bobbrow Compressing the dump file got it below the e-mail size limit. I've sent it to the e-mail address listed by sean. If you still need me to copy-paste my stack frames let me know, but I figured getting that to you would be quicker.

[bobbrow]

Thanks, we got it.

[bobbrow]

Found the bug. It is indeed an infinite loop in the compiler detection code.

Are you using MinGW? You should be able to work around this problem by adding "intelliSenseMode": "clang-x64" and listing the full path to your MinGW compiler in "compilerPath" in your c_cpp_properties.json file.

If you do not have a c_cpp_properties.json file because you haven't opened a folder, you will need to use the "C_Cpp.default.*" properties to set those values until we get a fix out.

[bobbrow]

Actually, what I said might not do anything. This loop is encountered before the configurations are even sent. We'll simply need to push a patch for this or you'll need to hide your MinGW-w64 folder from us. 😞

[neilhummus]

For me, that seems to be better, but not totally fixed. It will respond to the command now, but only ever pop up "no definition found for \

edit: @bobbrow that was in response to the link you had posted.

[bobbrow]

I removed it because I saw the same problems after posting. There was a pull request in the typescript code that I just approved that regressed this behavior. I'm fixing it now and I'll publish a new insiders shortly. You can uninstall the one I posted earlier.

[bobbrow]

This one should work better. Sorry about the misfire.

cpptools-win32.zip

[neilhummus]

Yes, that one is working correctly for me so far.

[montaguk]

I've installed the one you just linked an now I only get the "no definition found for " message when trying to search.

Things seemed to be working okay on the manually installed v0.17.0, so I'm not sure what else could be going on.

[bobbrow]

Just double checking, you got 0.17.2-master installed and you're still having a problem with goto definition?

[montaguk]

I think it was an issue with the c_cpp_properties.json file. I nuked my existing one and regenerated, and now goto seems to be working. However, now I have red squiggles under a bunch of symbols that are correctly resolved. Hitting F12 on a symbol with a red squiggle jumps directly to the correct definition.

Switching to clang-x64 makes all of the squiggles go away, but the UX of navigating around is not ideal. Seems like it could be related to #2008, but I'm not trying to use GCC.

Not sure if this is close enough within the backend to be covered by this issue, or if a new one needs to be created to track this.

[sean-mcmanus]

We have an insiders build you can try with the fix: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.2-insiders . The official release is planned tomorrow unless we get delayed by finding more bugs.

[montaguk]

I still have the red squiggles under nearly every symbol with the 0.17.02-insiders build, but at least goto seems to be working as expected now.

[bobbrow]

Can you set "C_Cpp.loggingLevel": "Debug" and then re-open one of the files that is giving you red squiggles to see if the include paths are being configured properly? The extension will print out the resolved include path and defines in the Output window (use the filter dropdown to select the C/C++ output)

[sean-mcmanus]

@montaguk Yeah, as Bob said, you should check the logs to see if the include paths contain the path to were the missing symbols are defined. It's possible we are filtering out a paths incorrectly (previous fixed bugs), or it could be a "by design" issue where a recursive include path happens to have a file with the same name, but in the incorrect directory, causing the wrong file to be used. This typically occurs when your project uses a headers with the same name as a standard library header. We've hit this ourselves internally and adding those unusually named file's directories to the files.exclude list is the work around we use. Explicitly adding the correct path before the recursive include could also resolve the issue.

[montaguk]

When opening a file with the red squiggles, I get a list of resolved include directories that appear to be correct. At the very least, I confirmed that the symbols that are marked with squiggles are indeed defined by files in the resolved directories. I included the output below, but removed actual filenames and paths due to NDA. Seems like the 'No suitable compiler' message could be indicative of a configuration issue on my side?

No suitable compiler found, system includes will be guessed
sending compilation args for ....FILENAME SCRUBBED...
  .... LIST OF INCLUDES SCRUBBED FOR NDA ....
  define: _DEBUG
  define: UNICODE
  define: _UNICODE
  stdver: --ms_c++latest
queue_update_intellisense for files in tu of: ....FILENAME SCRUBBED...
errorSquiggles count: 227

Update: Not sure if this means anything, but I've noticed that in the debug out there are numerous instances of the following message interspersed with the 'No suitable compiler...' message:

Attempting to get defaults from compiler found on the machine: C:\MinGW\bin\gcc.exe

I have multiple versions of MSVC installed, and my c_cpp_properties.json file is set to msvc-x64, so it seems odd that it's trying to use gcc from MinGW.

[bobbrow]

Which versions of MSVC do you have? Are you using the Build Tools SKU or Visual Studio?

Can you share the system include paths that were guessed? They should be at the end of the list. If you are providing your own system include paths via the includePath property, then you should be able to set "compilerPath": "" to tell the extension not to look for an alternate compiler.

[montaguk]

Visual Studio 2013 and 2008, both installed to C:\Program Files (x86)\Microsoft Visual Studio **. It's possible that I installed a Build Tools package for VS2017 at one point, but I'm not sure where to look to confirm.

I don't have any system include paths that show up in the list. Everything it locates is within the project. My includePath setting only has recursive includes for a couple of folders relative to ${workspaceFolder}.

[bobbrow]

Ok. That's the problem then. We don't detect VS 2013 or 2008. If you add "compilerPath": "" to your c_cpp_properties.json, it should stop the extension from using MinGW.

[montaguk]

Setting "compilerPath": "" doesn't seem to make the squiggles go away, but it does stop complaining about not being able to find a valid compiler. Seems that this is because it's been disabled entirely, rather than fixing the issue.

Are VS 2013/2008 compilers supported if I manually set the compilerPath? I tried doing that and complained about the options being passed in and the squiggles didn't go away.

As a last resort, I manually set the compilerPath to another version of MinGW that I have installed. Doing that seems to make the squiggles go away, but the system include paths are incorrect now. I think I can work through that issue though, as that seems to be behaving as expected. Ideally, I'd be able to point it at one of my MSVC toolchains and have it use that one.

[bobbrow]

No, VS 2013/2008 compilers are not supported at all (though maybe we should go back and add support in a future release). If you are not using VS 2015 or VS 2017, you need to add the system includes (including the Windows SDK paths) to the includePath manually.

[montaguk]

Gotcha. Am I correct in thinking that the compiler is only used to grab the system include paths? Or is it also use for syntax checking and/or other functionality?

[sean-mcmanus]

Currently, our IntelliSense is hardcoded to be configured for the VS 2017 compiler, so for certain peculiarities/bugs/etc. with the older compiler, there could be bugs (particularly if you try to use the cppStandard setting of c++17, which isn't supported on the older VS compilers). We plan to enable users to set the cl.exe path and query it for the correct version so the defines and flags will be configured correctly.

[bobbrow]

@montaguk correct, the compilerPath is only used to provide system include paths and defines.

[montaguk]

Good to know. I think I'm all squared away for now. Thanks to you both @bobbrow and @sean-mcmanus for all the help!