Vscode-cpptools: tag parser can't finish initializing and F12(go to definition) don't work

Created on 17 Dec 2019  Â·  5Comments  Â·  Source: microsoft/vscode-cpptools

Type: LanguageService

Describe the bug

  • OS and Version: Windows 10 (host), Ubuntu 16.04 (remote server)
  • VS Code Version: 1.41.0 (user setup)
  • C/C++ Extension Version: 0.26.2 (and 0.26.3-insider also have same behavior)
  • Other extensions you installed (and if the issue persists after disabling them): C++Intellisense 0.2.2

In lower right corner, there is a cylinder (may be the symbol of database?) always shows "tag parser initializing" and it can't finish.
When press F12 to go to definition shows "No definition found for ...".
OUTLINE shows "can't found any symbol" (something like that, I can't remember clearly. )

I tried to reinstall extensions and restart vscode but it doesn't work. I also tried to delete .vscode folder in my ${WORKSPACE} but it doesn't work either.

Finally, I found following workaround:

Workaround

  1. Close vscode remote connection and close vscode.
  2. Go to user home directory on remote server.
  3. Delete .vscode-server folder (rm -rf .vscode-server)
  4. Open vscode and connect to server again.

Sorry, I can't reproduce this issue, so I can't provide additional context.
I hope the information I have provided will be helpful.

Most helpful comment

Yeah, other users have reported a similar bug symptom. Changing the C_Cpp.Default.browse.databaseFilename setting to something like "${workspaceFolder}/.vscode/vc.db" may also fix it. The problem is the database at the default location is unusable, probably due to a dangling/old process locking the database and lock detection/fallback mechanism doesn't work well on Linux.

All 5 comments

Yeah, other users have reported a similar bug symptom. Changing the C_Cpp.Default.browse.databaseFilename setting to something like "${workspaceFolder}/.vscode/vc.db" may also fix it. The problem is the database at the default location is unusable, probably due to a dangling/old process locking the database and lock detection/fallback mechanism doesn't work well on Linux.

I just hit the same bug on my Linux machine...some old/dangling processes...killing them fixed it. I think VS Code isn't killing our processes as it used to when versions get uninstalled/installed. Maybe we need some mechanism to kill old processes to compensate for VS Code not handling this.

The similar problem once occurred in my vscode on Windows 10 too. I hit this bug on Windows 10 (not connect to remote server) in September. I just remove all cache folders of vscode to solve it.

What's the name of the process that should be killed?

@msafi It should start with Microsoft.VSCode.CPP.Extension (our next 0.27.0 release is renaming it to "cpptools" though).

Was this page helpful?
0 / 5 - 0 ratings