-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Language server crashing #12464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @spinicist . I'm having some difficulty reproducing the issue, with 1.20.5 on an M1 Mac. Following your repro steps (and updating my c_cpp_properties.json to match the content you provided), after I open the root directory, CMake Tools prompts me to select a compiler, however after selecting Apple Clang 14, it fails to configure the folder.
Is the repro occurring for you in this state, without getting the project fully configured? Other than opening With your configuration and in this state,
This log message indicates that a source file was open and a crash occurred in the IntelliSense process (
(from the other issue thread). This may be a different issue. This is pointing to a crash occurring in the main |
Hello, you'd need to run the bootstrap.sh script first I think, or at least invoke CMake with |
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
Hi @spinicist . I haven't forgotten about this, but I'm still not able to repro and am blocked from fully configuring IntelliSense (by using CMake Tools) due to the error I posted previously (with Are you still experiencing the problem with 1.21.6? I believe we have since fixed an issue that could result in a crash on macOS. |
It appears to still happen. I had downgraded to 1.18. I re-enabled auto-update to get v1.21.6 and restarted the extension. I was initially hopeful, as I didn't see the "Language Server crashed too many times" dialog. However, I wasn't getting any Intellisense hints in
I'll roll back to v1.18 again. |
@spinicist Are you able to get a crash call stack for cpptools-srv, either in the C/C++ Crash Call Stacks logging window or Mac's built-in crash logging output (or from attaching a debugger before it crashes, i.e. commenting out the crashing code and the uncommenting it). |
Crash Call Stacks has appeared as an option. Here is the output:
|
@spinicist We made some potential fixes with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.22.0, but we don't know yet whether it's actually fixed or not (the crash location may have just changed). |
Thanks @sean-mcmanus. I've updated to v1.21.6 and in the last 20 minutes have not observed a crash. It's looking good given how quickly it crashed before. Is there a short/simple explanation as to what was wrong? I'm curious. |
Spoke too soon.
|
Apologies for multiple posts. I realised that you suggested to upgrade to v1.22.0. For some reason my VS Code was not picking that up, so I ticked the pre-release button and upgraded to v1.22.2. Sadly that still crashes:
|
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
I tried updating to
|
I got a similar error on a mac m1 (sequoia). The lsp server cannot be connected, and after a timeout, here is the output: ending document notification textDocument/didOpen failed
Message: Client is not running
Code: -32096 Need to switch back to version 1.20.5. All recent versions have the same trouble... |
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
Hi @spinicist . The most recent stack you provided would appear to be a different issue. It appears to be an IntelliSense crash (from the cpptools-srv process, not cpptool), appears to be related to recursion, and is likely related to specific code that it's trying to parse. Would you be able to isolate that code and provide a minimum repro that triggers that crash? Hi @ramet. I don't believe the issue you're seeing is related. Could you open a new issue? Some additional diagnostics, such as requested in the new issue template, would be helpful. I don't believe we're aware of any issues impacting all arm64 macOS users, so your particular scenario or environment may be relevant. |
On my side, everything is back to normal. I am on the latest release. Thank you. |
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
I installed v1.22.11 today, and the crash persists:
|
Is there any way for me to get a line number / source code position on the entry to this call stack? This is moderately large code base and the crash seems to happen in any file I open, so I assume it's happening in a library header file. I have very little |
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
If I get some pointers about a sensible way to narrow down which file(s) are causing this crash I'm happy to try. |
Hey @Colengms, this issue might need further attention. @spinicist, you can help us out by closing this issue if the problem no longer exists, or adding more information. |
These are some strategies for edits that I use when trying to narrow down a repro:
Repeat these steps until you have something small or safe enough to share with us (e.g. no proprietary code) and we can take over from there. |
(oh, and keep copies of the original source, or start a new branch in your source control to make sure you don't lose any important code) |
This issue has been closed because it needs more information and has not had recent activity. |
I've tried 1.24.5 today and the issue persists. I tried to reduce the problem to a minimal example, but it makes zero sense. In my main project, the following file contents:
reliably produce this crash:
I copied the same file into a new, mostly empty project (CMake, vcpkg, one main.cpp file), and there are no crashes. Is there anyway to make the crash stack print the name/path of the translation unit it is trying to process? Because I'm finding hard to believe the contents of the tab are what it's trying to process. There are no other tabs open. |
@spinicist Is the TU using a forced include? It could also be using a stale/corrupt .ipch file. Can you try setting C_Cpp.intelliSenseCacheSize to 0? You could potentially set it back to 5120 afterwards. If you only have 1 source file open, then the TU and crashing cpptools-srv should be for that. You can try running C/C++: Log Diagnostics for translation unit info, but I'm not sure what it would show if it's crashing. If you're opening a header file, then it could be choosing some source file in your workspace to use with the header. Setting C_Cpp.loggingLevel to "Debug" and viewing the C/C++ output should show which source file is getting chosen. |
@spinicist Are you able to attach a debugger to cpptools-srv and then uncomment the code to cause the crash? That could allow us to get a better call stack. It looks like it's crashing in f_value_bytes_for_type, but our crash logging doesn't show the offset, but it might be shown in the debugger. |
I tried setting the cache size to 0, it still crashed. Where might a forced include be hiding? I used to use a forced include on this laptop to disable intellisense with NEON code. This was a long time ago (like 2 years, maybe?). My memory is the NEON problem was fixed long ago, and so I disabled the forced include. But maybe I didn't do that right? |
Gave up trying to find all the accumulated stale state on this laptop, so I removed and reinstalled VS Code. Now I get a different crash:
|
Intellisense really doesn't like my laptop, does it? |
Environment
Bug Summary and Steps to Reproduce
Bug Summary: "The language server crashed. Restarting..."
Steps to reproduce:
I have not had time to investigate whether this bug happens with other projects/repos, or whether it is required to run the bootstrap script first (a CMake/vcpkg build). The error log below suggests it is a problem parsing this file: https://github.com/spinicist/riesling/blob/main/cxx/riesling/basis/svd.cpp which I happened to have open at the time.
Expected behavior: The language server does not crash
Configuration and Logs
Other Extensions
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: