Can't create intellisense client for /usr/include/c++/8/ostream

[adrianhasse]

Type: LanguageService

Describe the bug

• OS and Version: Fedora 28
• VS Code Version: 1.25.1
• C/C++ Extension Version: 0.17.7

IntelliSense is not working, generating the following output:
Failed to read response from server: 18
Failed to create IntelliSense client. Can't create intellisense client for /usr/include/c++/8/ostream

In the following the file c_cpp_properties.json

{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward",
"/usr/lib/gcc/x86_64-redhat-linux/8/include",
"/usr/local/include",
"/usr/include",
"/opt/or-tools_CentOS-7.3.1611-64bit_v6.4.4495/include"
],
"defines": [],
"intelliSenseMode": "clang-x64",
"browse": {
"path": [
"${workspaceFolder}",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux",
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward",
"/usr/lib/gcc/x86_64-redhat-linux/8/include",
"/usr/local/include",
"/usr/include",
"/opt/or-tools_CentOS-7.3.1611-64bit_v6.4.4495/include"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": "",
"cStandard": "c11",
"cppStandard": "c++17",
"compilerPath": "/usr/bin/gcc"
}
}
],
"version": 4
}

If more information is needed let me know and I will provide them. Help is much appreciated.

[sean-mcmanus]

It looks like the Microsoft.VSCode.CPP.IntelliSense.Msvc.linux process is crashing. Are you able to provide a call stack of the crashing thread? Otherwise, we'll need to try to get a repro. Our pending change to enable gcc-x64 mode with a higher version, might cause this to no longer repro as well.

[adrianhasse]

Since the process crashes directly after the extension is started, I do not know how to provide you with a call stack. Do you have some instructions I can follow?

[sean-mcmanus]

Some people have configured their Linux OS to generate a core dump files. There's documentation at https://linux.die.net/man/5/core , but I'm not sure if that works with Fedora. You can also try running the process from the command line from the <user>/.vscode/extensions/ms-vscode.cpptools-0.17.7/bin folder to make sure it doesn't fail or give some missing dependency message. You could also try using a different compiler or excluding certain header files or using a simpler project to try to narrow down the repro requirements of the crash.

Ideally, we would add some special way for users to freeze the intellisense process on startup to make it easier to attach a debugger before it crashes.

[sean-mcmanus]

I got gcc 8 (the Linux-gnu version though, not the redhat one), but I'm not able to repro the crash via opening ostream, but we're aware of another crash involving "set": #2328 .

[adrianhasse]

I think this is also my problem because I am using "unordered_map". I also could reproduce it:

#include <iostream> #include <unordered_map> int main() { std::unordered_map<int, int> _map_output; _map_output.emplace(5, 5); std::cout << "Hello world!" << std::endl; std::cout << "Press enter..." << std::endl; std::cin; }

As soon as I add the line "_map_output.emplace(5, 5);" intellisense is not working anymore with the following message: "Failed to read response from server: 18"

[sean-mcmanus]

Yeah, thanks for the info -- I get the same crash call stack with your unordered_map repro (code in 8/bits/unordered_map.h causes the crash), so it looks like it's the same issue as the stl_tree.h crash.

[sean-mcmanus]

This is a regression from our previous release after we updated our parser code. So you can use our previous 0.17.6 version as a workaround, setting extensions.autoUpdate to false to avoid getting the newer version: https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.6 .

[sean-mcmanus]

The root cause is our compiler's lack of support for the __is_assignable intrinsic added to gcc-8. You can work around this via adding this define to your c_cpp_properties.json:
"__is_assignable(a, b)=true" (our previous version was more resilient to the missing intrinsic). Let us know if you notice any issues with this workaround.

Also, (at your own risk/discretion) you could also modify your gcc-8 type_traits headers to get rid of the __is_assignable intrinsic usage (see gcc-mirror/gcc@b4d90ee ).

[adrianhasse]

Many thanks for the quick and competent help.

[adrianhasse]

Just a quick update, the second fix ( not the rollback) leads to a problem with the debugger (GDB), which crashes without any particular error message.

[sean-mcmanus]

@adrianhasse What's the 2nd fix mean? Oh -- you mean modifying the type_traits header? Yeah, if GDB has a problem with that modification you should undo it. Have you tried our 0.17.8-insiders build at https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.17.8-insiders ? We plan to release a non-Insiders release with the fix in a day or two.

[sean-mcmanus]

Fixed with 0.18.0.