Language Server Crashed
Environment
- OS and Version: Windows 7
- VS Code Version: 1.70.3
- C/C++ Extension Version: 1.17.5
- If using SSH remote, specify OS of remote machine:
Bug Summary and Steps to Reproduce
The language server crashed every time I open VSCode
Configuration and Logs
{
"version": 0,
"configurations": [],
"enableConfigurationSquiggles": true
}
C/C++ logging:
cpptools version (TypeScript): 1.17.5
cpptools version (native): 1.17.5.0
Autocomplete is enabled.
Error squiggles are enabled if all header dependencies are resolved.
Hover is enabled.
IntelliSense Engine = default.
LSP: cpptools/queryCompilerDefaults (id: 1)
Querying compiler for default C++ language standard using command line: E:\MinGw\bin\gcc.exe -x c++ -E -dM nul
Detected language standard version: gnu++17
Querying compiler's default target using command line: "E:\MinGw\bin\gcc.exe" -dumpmachine
Compiler returned default target value: x86_64-w64-mingw32
Compiler query command line: E:\MinGw\bin\gcc.exe -std=c17 -m64 -Wp,-v -E -dM -x c nul
Attempting to get defaults from C compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
Compiler query command line: E:\MinGw\bin\gcc.exe -std=gnu++17 -m64 -Wp,-v -E -dM -x c++ nul
Attempting to get defaults from C++ compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
LSP: cpptools/didChangeCppProperties (id: 2)
LSP: textDocument/didOpen: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: cpptools/activeDocumentChange: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 3)
LSP: cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 4)
LSP: cpptools/getCodeActions: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 5)
LSP: cpptools/getInlayHints: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 6)
LSP: textDocument/hover: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 7)
Warning: Database safety check failed. Recreating database.
[rc=0x80004005] (DB: false, Expected: true)
Code browsing service initialized
Compiler query command line: E:\MinGw\bin\gcc.exe -std=c++11 -m64 -Wp,-v -E -dM -x c++ nul
Attempting to get defaults from C++ compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
Folder: E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE/ will be indexed
Folder: E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE-FIXED/ will be indexed
Folder: E:/MINGW/X86_64-W64-MINGW32/INCLUDE/ will be indexed
Folder: E:/ZES/VSCODE/CPP/ will be indexed
Discovering files...
Processing folder (recursive): E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE/
tag parsing file: E:\zes\VSCode\cpp\test.cpp
CPPTools logging: single line
[Error - 20:19:07] The language server crashed. Restarting...
Other Extensions
Additional context
No response
Are you able to attach a debugger to cpptools.exe to get a call stack? It could be a duplicate of https://github.com/microsoft/vscode-cpptools/issues/11781 .
It looks like it might be crashing while trying to tag parse a particular file.
Are you able to attach a debugger to cpptools.exe to get a call stack? It could be a duplicate of #11781 .
It looks like it might be crashing while trying to tag parse a particular file.
@sean-mcmanus
How to debug it when vscode is being opened? I've attached GDB v11.2 to cpptools.exe with the following configurations. When I start debugging it just go stuck and a thread exited with code 0. Nothing else occurred. I guess it is just incorrect to debug it directly. As a noob I feel sorry to have no idea about that. Could you tell me about that in detail?
"configurations": [
{
"name": "Debug cpptools with GDB",
"type": "cppdbg",
"request": "launch",
"program": "C:\\Users\\Administrator\\.vscode\\extensions\\ms-vscode.cpptools-1.17.5-win32-x64\\bin\\cpptools.exe",
"args": [],
"stopAtEntry": false,
"cwd": "C:\\Users\\Administrator\\.vscode\\extensions\\ms-vscode.cpptools-1.17.5-win32-x64\\bin\\",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "gdb"
}
=thread-group-added,id="i1"
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
I've corrected the targetArchetecture to "x64" but it does nothing but remove the warning
I've corrected the targetArchetecture to "x64" but it does nothing but remove the warning
Could you explain a bit more about the background project?
We have the same issue in my company and seems that could be a workaround, at least on our scenario. I don't know what could be the impact.
Check my thread #11745 Try to put this c_cpp_properties.json:
c_cpp_properties.json
{
"configurations": [
{
"name": "test-linux",
"includePath": [
"${default}",
"${workspaceFolder}/**",
],
"defines": [],
"cStandard": "c17",
"cppStandard": "c++14",
"intelliSenseMode": "linux-clang-x64"
}
],
"version": 4
}
If you still face the same issue, try adding this to settings.json
{
"cmake.loadCompileCommands": false
}
I'm just a beginner and I just want to open the editor
Hi @Zes-MinKey-Young . The log you posted indicated version 1.17.5 of the C/C++ extension. Are you still experiencing this issue with the latest version? We have since addressed a known crash on startup (related to trying to process malformed JSON settings values). That was fixed in 1.18.3, but I'd suggest trying the very latest insiders (currently 1.19.1, though 1.19.2 should be available soon), to rule out issues that may have already been addressed. I don't there are any remaining start-up crashes on our radar, so if you or @borjamunozf are still reproducing an issue and can help by providing us log output, system and configuration details, we would be keen to investigate further.
@Colengms Yes, I'm still faced with this problem. logging output:
LSP: (received) cpptools/initialize (id: 1)
LSP: (invoked) cpptools/initialize (id: 1)
cpptools version (TypeScript): 1.19.2
cpptools version (native): 1.19.2.0
Autocomplete is enabled.
Error squiggles are enabled if all header dependencies are resolved.
Hover is enabled.
IntelliSense Engine = default.
LSP: Sending response (id: 1)
LSP: (received) cpptools/queryCompilerDefaults (id: 2)
LSP: (invoked) cpptools/queryCompilerDefaults (id: 2)
Querying compiler for default C++ language standard using command line: E:\MinGw\bin\gcc.exe -x c++ -E -dM nul
Detected language standard version: gnu++17
Querying compiler's default target using command line: "E:\MinGw\bin\gcc.exe" -dumpmachine
Compiler returned default target value: x86_64-w64-mingw32
Compiler query command line: E:\MinGw\bin\gcc.exe -std=c17 -m64 -Wp,-v -E -dM -x c nul
Attempting to get defaults from C compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
Compiler query command line: E:\MinGw\bin\gcc.exe -std=gnu++17 -m64 -Wp,-v -E -dM -x c++ nul
Attempting to get defaults from C++ compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
LSP: Sending response (id: 2)
LSP: (received) cpptools/didChangeCppProperties (id: 3)
LSP: (received - deferred) textDocument/didOpen: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: (invoked) cpptools/didChangeCppProperties (id: 3)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 4)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 5)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 6)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 7)
LSP: (received - deferred) cpptools/didChangeVisibleTextEditors
Warning: Database safety check failed. Recreating database.
[rc=0x80004005] (DB: false, Expected: true)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 8)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 9)
LSP: $/cancelRequest (cpptools/getDocumentSymbols, id: 4)
LSP: $/cancelRequest (cpptools/getDocumentSymbols, id: 5)
LSP: $/cancelRequest (cpptools/getDocumentSymbols, id: 6)
LSP: $/cancelRequest (cpptools/getDocumentSymbols, id: 7)
Code browsing service initialized
Compiler query command line: E:\MinGw\bin\gcc.exe -std=c++11 -m64 -Wp,-v -E -dM -x c++ nul
Attempting to get defaults from C++ compiler in "compilerPath" property: 'E:\MinGw\bin\gcc.exe'
Folder: E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE/ will be indexed
Folder: E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE-FIXED/ will be indexed
Folder: E:/MINGW/X86_64-W64-MINGW32/INCLUDE/ will be indexed
Folder: E:/ZES/VSCODE/CPP/ will be indexed
LSP: (queued) textDocument/didOpen: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 4)
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 5)
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 6)
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 7)
LSP: (queued) cpptools/didChangeVisibleTextEditors
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 8)
LSP: (queued) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 9)
LSP: Sending response (id: 3)
LSP: (invoked) textDocument/didOpen: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 4)
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 5)
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 6)
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 7)
LSP: (invoked) cpptools/didChangeVisibleTextEditors
Discovering files...
Intellisense update pending for: file:///e%3A/zes/VSCode/cpp/test.cpp
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 8)
LSP: (invoked) cpptools/getDocumentSymbols: file:///e%3A/zes/VSCode/cpp/test.cpp (id: 9)
Processing folder (recursive): E:/MINGW/LIB/GCC/X86_64-W64-MINGW32/12.2.0/INCLUDE/
tag parsing file: E:\zes\VSCode\cpp\test.cpp
cpptools output is still a single line.
Hi @Zes-MinKey-Young . Since we're not tracking an issue impacting everyone, there would seem to be something about your environment or configuration that we may need to identify to reproduce and address the issue.
In your most recently log, I noticed that a crash did not occur until test.cpp was opened. Is there anything special about the contents of this file? Does the crash occur when using an empty file ending in .cpp, or does it require the contents of that particular file to repro the issue? Could the issue be related to the encoding (i.e. UTF-8 vs ?) of the source file?
Was the configuration in your first message the contents of your c_cpp_properties.json? With that contents, I get:
Invalid configuration file. There must be at least one configuration present in the array.
Could you clarify the contents of your c_cpp_properties.json or equivalent C_Cpp settings that you're using to configure the C/C++ Extension?
Does this problem repro for you with a simple scenario, such as a folder with a single simple source file, and no particular configuration?
Can you refer us to which of the MinGW distribution you are using, and perhaps which compiler package you've installed?
(So strange that the browser failed in posting my reply the day before yesterday, or you would have see this at that time)
Crash still occurrs with no content in test.cpp and the removal of c_cpp_properties.json:
And the original is a simple helloworld:
Configuration:
{
"configurations": [
{
"name": "test-windows",
"includePath": [
"${default}",
"${workspaceFolder}/**"
],
"defines": [],
"cStandard": "c17",
"cppStandard": "c++14",
"intelliSenseMode": "windows-gcc-x86"
}
],
"version": 4
}
C:\Users\Administrator>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=E:/MinGw/bin/../libexec/gcc/x86_64-w64-mingw32/12.2.0/lto-wr
apper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-12.2.0/configure --host=x86_64-w64-mingw32 --b
uild=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sys
root=/c/buildroot/x86_64-1220-posix-seh-rt_v10-rev0/mingw64 --enable-host-shared
--disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time
=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --e
nable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-
version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-lib
stdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disabl
e-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as
--with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system
-zlib --with-gmp=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-mpf
r=/c/buildroot/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/buildroot/p
rerequisites/x86_64-w64-mingw32-static --with-isl=/c/buildroot/prerequisites/x86
_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-
W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O
2 -pipe -fno-ident -I/c/buildroot/x86_64-1220-posix-seh-rt_v10-rev0/mingw64/opt/
include -I/c/buildroot/prerequisites/x86_64-zlib-static/include -I/c/buildroot/p
rerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -
I/c/buildroot/x86_64-1220-posix-seh-rt_v10-rev0/mingw64/opt/include -I/c/buildro
ot/prerequisites/x86_64-zlib-static/include -I/c/buildroot/prerequisites/x86_64-
w64-mingw32-static/include' CPPFLAGS=' -I/c/buildroot/x86_64-1220-posix-seh-rt_v
10-rev0/mingw64/opt/include -I/c/buildroot/prerequisites/x86_64-zlib-static/incl
ude -I/c/buildroot/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pi
pe -fno-ident -L/c/buildroot/x86_64-1220-posix-seh-rt_v10-rev0/mingw64/opt/lib -
L/c/buildroot/prerequisites/x86_64-zlib-static/lib -L/c/buildroot/prerequisites/
x86_64-w64-mingw32-static/lib ' LD_FOR_TARGET=/c/buildroot/x86_64-1220-posix-seh
-rt_v10-rev0/mingw64/bin/ld.exe --with-boot-ldflags=' -Wl,--disable-dynamicbase
-static-libstdc++ -static-libgcc'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
version : MinGW-W64-builds-5.0.0
user : runneradmin
date : 08.22.2022- 5:09:19 AM
args : --mode=gcc-12.2.0 --buildroot=/c/buildroot --jobs=4 --rev=0 --rt-version=v10 --threads=posix --exceptions=seh --arch=x86_64 --bin-compress --enable-languages=c,c++,fortran
PATH : /mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
CFLAGS : -O2 -pipe -fno-ident
CXXFLAGS: -O2 -pipe -fno-ident
CPPFLAGS:
LDFLAGS : -pipe -fno-ident
#
@Colengms
@sean-mcmanus
@Colengms Was there more info needed still?
@Zes-MinKey-Young Is there some scenario where it can be made to not crash?
@sean-mcmanus How can I find one scenario? It is just a simple open-up and I even could not start my c++ coding :(
any update? same problem
Hi @shenjiangqiu . Could you open a new issue with your repro details? Since this issue is very general and not yet understood, it's possible you're seeing something with a different root cause.
@Zes-MinKey-Young I don't believe we have enough information to investigate this yet. Does this repro for you on another system? Does it repro without any other extensions installed? I do see many instances of getDocumentSymbols in your log, which I do not repro locally. Perhaps another extension is issuing a flood of these requests?
I also see that your database is indicated as being corrupted, and the crash occurs later, on the first attempt to 'tag parse' a file, which would ingest it into the database. There could be some issue with accessing your database or database path. Could you try specifying a new location for that database using the C_Cpp.default.browse.databaseFilename setting, or the equivalent field in c_cpp_properties.json?
Also, could you provide updated logs from the latest version of the C/C++ extension (1.20.0 insiders)?
@Colengms I tried to reinstall the whole operating system(from archlinux to ubuntu 22.04) and this problem consist. The log shows: (last lines before crash)
Warning: Database safety check failed. Recreating database.
[rc=0x80004005] (DB: false, Expected: true)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///home/sjq/Docs/main.cc (id: 4)
LSP: (received - deferred) cpptools/getDocumentSymbols: file:///home/sjq/Docs/main.cc (id: 5)
LSP: (received - deferred) cpptools/getCodeActions: file:///home/sjq/Docs/main.cc (id: 6)
LSP: (received - deferred) cpptools/didChangeActiveEditor: file:///home/sjq/Docs/main.cc
LSP: (received - deferred) cpptools/resumeParsing
LSP: (received - deferred) cpptools/didChangeVisibleTextEditors
something I have tried:
- [x] Different version of c++ extension(release and pre-release)
- [x] Different OS(archlinux and ubuntu 22.04)
- [x] Different code-server installation place( from one disk to another disk)
Now, I doubt it might be a hardware issue. Any suggestions how to test it?
maybe:
- [ ] install OS in another new disk
@shenjiangqiu What is your C_Cpp.loggingLevel set to?
Hi @shenjiangqiu . Could you open a new issue and provide the information requested in the new issue template? There are many possible reasons a crash can occur, and it's possible your crash is not the same as encountered by the user who opened this issue.
To see what's going on, it would really help to have the following information:
- The output from the C/C++ output panel, from launch until the repro, with the
"C_Cpp.loggingLevel": "Debug"setting enable. This may refer to a particular feature that is failing or a file that is being parsed when the issue occurs. - If the repro involves parsing specific code, code that can be used to reproduce the issue.
- Information about your repro environment - are you remoting into the machine or using it locally? What is the architecture (x64, arm64, etc.) of the system?
@Colengms @sean-mcmanus I have created an new issue: https://github.com/microsoft/vscode-cpptools/issues/12201 #12201
Hey @Colengms, this issue might need further attention.
@Zes-MinKey-Young, you can help us out by closing this issue if the problem no longer exists, or adding more information.
This issue has been closed because it needs more information and has not had recent activity.