use
commented
3 years ago Installing 1.6.0 on WSL: Ubuntu fixes the issue. 1.7.0 and 1.7.1 both cause the crash.
Closed use closed 2 years ago
use
commented
3 years ago Installing 1.6.0 on WSL: Ubuntu fixes the issue. 1.7.0 and 1.7.1 both cause the crash.
Colengms
commented
3 years ago Hi @use . Since this isn't a widely experienced issue, I suspect there is something specific to your environment or configuration.
Using 1.7.x, is it possible to get the C/C++ extension to activate without immediately crashing? (i.e. if you open an empty folder and trigger activation of the C/C++ extension by running C/C++: Edit Configurations (JSON))? Would it be possible to attach a debugger (i.e. gdb or lldb) to cpptools prior to the crash, to collect crash stacks?
You might also consider deleting the 1.7.x extension (i.e. from ~/.vscode-server/extensions/ms-vscode.cpptools-1.7.1) before reinstalling it. If it's become corrupted on your system somehow, reinstalling via VS Code might not actually result in a fresh copy. Deleting the cached copy would address that.
Can you confirm whether removing all C_Cpp.* related settings avoids the issue? If so, could you narrow down which settings seem to be involved in the repro?
use
commented
2 years ago Using 1.7.x, is it possible to get the C/C++ extension to activate without immediately crashing? (i.e. if you open an empty folder and trigger activation of the C/C++ extension by running C/C++: Edit Configurations (JSON))? Would it be possible to attach a debugger (i.e. gdb or lldb) to cpptools prior to the crash, to collect crash stacks?
I'm now using the latest vs code which auto installed for me today. I tried opening a new vscode window, opening a new folder outside of any c project, and creating a new empty file "nothing.c". As soon as the file buffer opens I get "Connection to server got closed. Server will not be restarted." followed by "The language server crashed 5 times in the last 3 minutes. It will not be restarted.".
Can you confirm whether removing all C_Cpp.* related settings avoids the issue? If so, could you narrow down which settings seem to be involved in the repro?
I took a look in settings.json. The only setting I have related to this extension is ""C_Cpp.loggingLevel": "Debug"" which I commented out and repeated the issue.
Using 1.7.x, is it possible to get the C/C++ extension to activate without immediately crashing? (i.e. if you open an empty folder and trigger activation of the C/C++ extension by running C/C++: Edit Configurations (JSON))? Would it be possible to attach a debugger (i.e. gdb or lldb) to cpptools prior to the crash, to collect crash stacks?
My apologies, I don't know how to do that. Is there a way to see how or why the language server crashed?
demin-dmitriy
commented
2 years ago Since this isn't a widely experienced issue, I suspect there is something specific to your environment or configuration.
Ubuntu 21.10, I am experiencing the same symptoms with 1.7.1. Reverted to 1.6.0, now it works as normal.
Can it be caused by some cache files?
Colengms
commented
2 years ago Hi @use . I'd like to confirm if the issue is related to opening a source file, or if the C/C++ extension is failing to activate at all. Could you confirm this by launching VS Code such that no source files are open at all, then opening on the C/C++ configuration file (c_cpp_properties.json), by running the C/C++: Edit Configurations (JSON) command). That will activate the C/C++ extension without processing a source file.
Does the issue happen when you open a local folder, or only when you open a remote folder via WSL? (Do you know if you are using WSL1 or WSL2?)
If the extension is unable to start at all, it could have become corrupted. Consider deleting the extension files from the file system before reinstalling (so VS Code does not reuse them). For the remote/WSL Linux, extension files would be in: ~/.vscode-server/extensions
I don't know how to do that. Is there a way to see how or why the language server crashed?
We could determine why it crashed if we can attach a debugger to it before it crashes, then trigger the crash. If we can catch it crashing while in the debugger, we could get a stack crawl (backtrace) of the crash, which would tell us a lot.
However, if the extension is not working at all, it may be that the extension itself is corrupted, or there is something about your setup that is unusual that we may need to identify in order to reproduce and investigate the issue.
maple3142
commented
2 years ago I have the same problem with version 1.7.0 and 1.7.1, rolling back to 1.6.0 works fine. Using vscode wsl remote in ArchWSL (WSL2).
Without opening any source file, running C/C++: Edit Configurations (JSON) opens c_cpp_properties.json just fine. But it will suddenly shows Connection to server got closed. Server will not be restarted. once I open any .c or .cpp file.
sean-mcmanus
commented
2 years ago @maple3142 The logging suggests you may be hitting a tag parser crash, but I'm not sure which file because the logging may be incomplete when the crash occurs. Can you open a workspace with a configuration like:
{
"name": "Linux",
"includePath": [
],
"compilerPath": "",
"browse": {
"path": []
}
}and then open a .cpp file to verify no crash occurs, and open various files (and/or adding folders to the configuration) to try to determine which file triggers the crash, e.g. opening /home/maple3142/tmp/Python39/include/cpython/abstract.h or pasting its contents into a file (or adding /home/maple3142/tmp/Python39/include/cpython/ to the includePath, etc.)?
Also, attaching a debugger to cpptools (see https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv ) before it crashes to get a crash call stack may also help...it would show if it's a tag parser crash or something else.
maple3142
commented
2 years ago Attaching a debugger then open a c file will immediately show one of the thread crashes, and here is its call stack:
msvc::base_channel_t::interface_from_context_helper(msvc::object_context_t const&, std::shared_ptr<msvc::base_interface_t> (*)(msvc::object_context_t const&, std::shared_ptr<msvc::channel_t> const&)) (Unknown Source:0)
void msvc::deserialize_interface<cpp_intellisense::server>(msvc::deserializer_t&, std::shared_ptr<cpp_intellisense::server>&) (Unknown Source:0)
cpp_intellisense::create_server(msvc::service_proxy_t&, std::shared_ptr<cpp_intellisense::server>&) (Unknown Source:0)
intellisense_client::create_server() (Unknown Source:0)
intellisense_client::init() (Unknown Source:0)
intellisense_client::create(char const*, char const*, compilation_args const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned long, bool) (Unknown Source:0)
create_sync_work(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*, unsigned long, std::shared_ptr<browse_engine>, std::shared_ptr<compilation_args_provider>, bool, bool) (Unknown Source:0)
create_async_work(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char const*, unsigned long, std::shared_ptr<browse_engine>, std::shared_ptr<compilation_args_provider>, bool) (Unknown Source:0)
std::_Function_handler<void (), intellisense_client_factory::create_async(char const*, char const*, char const*, std::shared_ptr<browse_engine>, std::shared_ptr<compilation_args_provider>, bool, std::function<void (std::vector<std::shared_ptr<intellisense_client>, std::allocator<std::shared_ptr<intellisense_client> > >)>&&, std::function<void ()>&&)::$_4>::_M_invoke(std::_Any_data const&) (Unknown Source:0)
std::_Function_handler<void (), msvc::thread_pool::enqueue(std::function<void ()>, std::future<void>*)::$_2>::_M_invoke(std::_Any_data const&) (Unknown Source:0)
msvc::thread_pool::do_work(unsigned long) (Unknown Source:0)
execute_native_thread_routine (Unknown Source:0)
libpthread.so.0!start_thread (Unknown Source:0)
libc.so.6!clone (Unknown Source:0)@maple3142 You're hitting https://github.com/microsoft/vscode-cpptools/issues/8312 -- it's fixed with our latest insiders at https://github.com/microsoft/vscode-cpptools/releases/tag/1.8.0-insiders2 . Updating your motherboard bios is another way to fix it.
github-actions[bot]
commented
2 years ago This issue has been closed automatically because it needs more information and has not had recent activity.
harshil21
commented
2 years ago Hi, can this issue be reopened? I'm also facing the same issue.
System info: WSL2 ubuntu extension version is 1.8.4. Windows 11
I just followed this guide: https://code.visualstudio.com/docs/cpp/config-wsl and got the "Connection to server got closed. Server will not be restarted." when I opened a .cpp file.
I also cleared the extension data at ~/.vscode-server/extensions and reinstalled the extension. Didn't solve the issue.
Here is the output shown when the extension crashes for the first time:
for some reason, I don't get the option to select cpptools or cpptools-srv when I follow this guide, so I can't attach the debugger:
https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv
sean-mcmanus
commented
2 years ago @harshil21 A language server crash is a symptom for which there are many potential causes. I've moved your issue to https://github.com/microsoft/vscode-cpptools/issues/8871 .
Issue Type: Bug
At some point the C/C++ language server stopped working. It crashes when I open any project. It used to work and I don't know why it stopped working.
This is with the latest Windows 10 and the latest extension version. I'm using WSL "Ubuntu 20.04.3 LTS".
Can you point me in the right direction as far as troubleshooting?
Extension version: 1.7.1 VS Code version: Code 1.62.3 (ccbaa2d27e38e5afa3e5c21c1c7bef4657064247, 2021-11-17T08:11:14.551Z) OS version: Windows_NT x64 10.0.19044 Restricted Mode: No Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2
System Info
|Item|Value| |---|---| |CPUs|AMD Ryzen 5 3600 6-Core Processor (12 x 3600)| |GPU Status|2d_canvas: enabledgpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|31.95GB (23.38GB free)| |Process Argv|--folder-uri=vscode-remote://wsl+Ubuntu/home/will/wkg/nn --remote=wsl+Ubuntu --crash-reporter-id 141764ab-b5b8-433d-8e09-06d378dfe9c5| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|WSL: Ubuntu| |OS|Linux x64 5.10.16.3-microsoft-standard-WSL2| |CPUs|AMD Ryzen 5 3600 6-Core Processor (12 x 3600)| |Memory (System)|25.02GB (22.70GB free)| |VM|0%|
A/B Experiments
``` vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 vswsl492cf:30256860 pythontb:30283811 pythonvspyt551:30345470 pythonptprofiler:30281270 vsdfh931cf:30280410 vshan820:30294714 vstes263:30335439 vscoreces:30384385 pythondataviewer:30285071 vscod805cf:30301675 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 dockerwalkthru:30377721 bridge0723:30353136 pythonrunftest32:30373476 pythonf5test824:30373475 javagetstartedt:30391933 pythonvspyt187:30373474 vsqsis200:30402083 vsaa593cf:30376535 vssld246cf:30401891 vscexrecpromptt2:30404948 vscop804:30404766 vscop453:30404998 ```