cpptools crash - `The language server crashed. Restarting...`

[Colengms]

We're very interested in fixing crashes. Information that could help us fix crashes include:

• Crash stacks.
• Specific guidance on how to repro a crash.
• Isolated examples that reproduce a crash and can be shared with us directly.

If you're experiencing a crash, any of the above information could be extremely useful to us to investigate and fix it. Please consider opening a new issue in this repo. Or, add a comment on this issue.

I'm pinning this issue, to make this more obvious to users who might be browsing our repo due to experiencing a crash.

[H-G-Hristov]

Just to remind that on macOS: https://github.com/microsoft/vscode-cpptools/issues/9810

[sean-mcmanus]

@H-G-Hristov Yes, but that issue mentions a work around via running lldb -p <processId>, then continue (assume it gets into a stopped state), and then repro the crash, and use bt to get the full stack of the crashing thread (maybe bt all if bt isn't sufficient for some reason).

[sean-mcmanus]

I've reproed multiple crashes. I'm tracking it with https://github.com/microsoft/vscode-cpptools/issues/10636 .

We may not need this issue anymore.

[Colengms]

Reopening. The intent of this issue was to be pinned so users experiencing a crash can find the issue and easily find instructions. I'd like to keep this open and pinned for now.

[sean-mcmanus]

@Colengms Yeah, that seems fine, but user should know that we don't currently have a widespread crashing issue (as of https://github.com/microsoft/vscode-cpptools/releases/tag/v1.14.5 or later).

[OnielN14]

I also encountered similar issue. OS: Windows 11 VS Code version : 1.81.0 C/C++ Extension version: 1.16.3

here is what I found when I check the log in developer tools :

ERR [Extension Host] (node:20304) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `Code --trace-deprecation ...` to show where the warning was created)

[OnielN14]

I also encountered similar issue. OS: Windows 11 VS Code version : 1.81.0 C/C++ Extension version: 1.16.3

here is what I found when I check the log in developer tools :

ERR [Extension Host] (node:20304) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(Use `Code --trace-deprecation ...` to show where the warning was created)

I just try to manually install the extension into fresh VSCodium v1.81.0.. the extension works

[chris0306]

大佬，这个问题怎么破？

[doxxx]

Working with a large Visual Studio solution of ~70 C# projects and one C++/CMake project. Also had the same solution open in Visual Studio at the same time. Performed a Rebuild in Visual Studio and then came back to 10000+ duplicate errors in VS Code like this:

[Error - 9:24:53 AM] Sending notification cpptools/fileDeleted failed.
Error: Cannot call write after a stream was destroyed
	at new NodeError (node:internal/errors:387:5)
	at _write (node:internal/streams/writable:323:11)
	at Writable.write (node:internal/streams/writable:336:10)
	at c:\Users\gordon.tyler\.vscode\extensions\ms-vscode.cpptools-1.16.3-win32-x64\dist\main.js:77222:29
	at new Promise (<anonymous>)
	at WritableStreamWrapper.write (c:\Users\gordon.tyler\.vscode\extensions\ms-vscode.cpptools-1.16.3-win32-x64\dist\main.js:77212:16)
	at StreamMessageWriter.doWrite (c:\Users\gordon.tyler\.vscode\extensions\ms-vscode.cpptools-1.16.3-win32-x64\dist\main.js:76424:33)
	at c:\Users\gordon.tyler\.vscode\extensions\ms-vscode.cpptools-1.16.3-win32-x64\dist\main.js:76415:29
	at runNextTicks (node:internal/process/task_queues:61:5)
	at process.processImmediate (node:internal/timers:437:9)

[sean-mcmanus]

@OnielN14 @chris0306 @doxxx That info is insufficient. We more info, particular the info that's described in the description for this issue, such as a call stack of cpptools or a repro.

[sean-mcmanus]

@OnielN14 @chris0306 @doxxx Also, 1.17.1 and 1.17.2 of our extension has some crash fixes, so that may be worth trying.

[vineetsoni]

I start to have the same issue since the extension auto-updated to 1.17.3 today. I'm running AlmaLinux 8.8 with kernel 4.18.0-477.15.1.el8_8.x86_64. The VSCode version is 1.81

Not sure if this is any useful, but the output message is:

[Error - 2:14:08 PM] The language server crashed. Restarting...
[Error - 2:14:08 PM] Sending document notification textDocument/didOpen failed
Error: Attempting to use languageClient before initialized
	at DefaultClient.get languageClient [as languageClient] (/u/vinson3z/.vscode-server/extensions/ms-vscode.cpptools-1.17.3-linux-x64/dist/main.js:47283:19)
	at DefaultClient.sendDidOpen (/u/vinson3z/.vscode-server/extensions/ms-vscode.cpptools-1.17.3-linux-x64/dist/main.js:48450:20)
	at DefaultClient.takeOwnership (/u/vinson3z/.vscode-server/extensions/ms-vscode.cpptools-1.17.3-linux-x64/dist/main.js:48439:20)
	at processDelayedDidOpen (/u/vinson3z/.vscode-server/extensions/ms-vscode.cpptools-1.17.3-linux-x64/dist/main.js:53325:30)
	at runMicrotasks (<anonymous>)
	at processTicksAndRejections (node:internal/process/task_queues:96:5)
	at async Function.dispatch (/u/vinson3z/.vscode-server/extensions/ms-vscode.cpptools-1.17.3-linux-x64/dist/main.js:48476:44)

Is there any known workaround for this problem?

Fixed the problem by downgrading to 1.16.3. Downgrading from 1.17.3 to 1.17.2 didn't work.

PS: This happens only when I try to use VSCode with a very large project. For a medium-sized project, it works fine.

[bobbrow]

@vineetsoni it looks like the extension isn't recovering from a crash properly. There were some code changes in this area recently, so thank you for reporting it. I'll move your report into a new issue.

[OnielN14]

hi @sean-mcmanus, thanks for your understanding.. mine suddenly works after cleaning up unused setting in vscode

[parsley72]

Mine crashes pretty regularly, I don't do anything specific to cause it. I just get: [Error - 3:39:38 PM] The language server crashed. Restarting...

Is there any more information I can get? For the debugging instructions in the first post, do I run that in a second instance of VSCode?

[Colengms]

For the debugging instructions in the first post, do I run that in a second instance of VSCode?

Hi @parsley72 . It should be possible to use same instance of VS Code. The debugger does not depend on the native component used by the C/C++ Extension for language services.

[medovanx]

I'm having the same issue? any work around?

[sean-mcmanus]

@medovanx The crash is a symptom for which there could be many causes. A workaround can't be provided without knowing the cause. You should file a new issue with more repro details.

[sean-mcmanus]

@vineetsoni cpptools crash recovery is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.17.4 . But the underlying cause of the crash isn't fixed (and if it crashes too many times in a row, the restarting will still be disabled).

[parsley72]

I tried but it's not working for me. I'm using WSL2 so when I edited the path I ended up with /home/tom/.vscode-server/extensions/ms-vscode.cpptools-1.17.5-linux-x64/bin/cpptools. When I run gdb and attach to the process I get this popup:

Ah, I had to add "miDebuggerPath": "/usr/bin/gdbus", https://stackoverflow.com/a/59939242/264822

[momoko-h]

I get this crash every time I try to run code analysis:

cpptools_backtrace.txt

[kasperbill]

I get this crash every time I start vscode with my workspace ... only error I can point to is

[Error - 7:01:29 PM] Sending document notification textDocument/didOpen failed Error: Cannot call write after a stream was destroyed at new NodeError (node:internal/errors:387:5) at _write (node:internal/streams/writable:323:11) at Writable.write (node:internal/streams/writable:336:10) at /Users/kasper/.vscode/extensions/ms-vscode.cpptools-1.17.5-darwin-arm64/dist/main.js:66111:29 at new Promise () at WritableStreamWrapper.write (/Users/kasper/.vscode/extensions/ms-vscode.cpptools-1.17.5-darwin-arm64/dist/main.js:66101:16) at StreamMessageWriter.doWrite (/Users/kasper/.vscode/extensions/ms-vscode.cpptools-1.17.5-darwin-arm64/dist/main.js:65229:33) at /Users/kasper/.vscode/extensions/ms-vscode.cpptools-1.17.5-darwin-arm64/dist/main.js:65220:29 [Error - 7:01:29 PM] The language server crashed. Restarting...

[MArKy1998]

I got crashed everytime I open folder which contains C/C++ files. C/C++ Extension v 1.17.5 IntelliSense and Indexing Workspace keep loading Errors suddenly appeared 2 weeks ago when I open VSCode. Tried to install old ver of C/C++ Extension but does not work. I really need this extension for "go to definition" function with "Ctrl + Click" If any one has extra solution please help or can guide me for gathering more info that can have to fix this crash

[lexx-spb-ru]

I experience crashes on opening some of my C++ project files (not every file) since I've updated cpptools extension to v.1.17.0 All versions after 1.17.0 (including 1.17.0) are affected by same crash I've disabled ALL other extensions - nothing helped

Attached crashstack files for 1.17.0 and 1.18.0. crashstack_cpptools_1.17.0.log crashstack_cpptools_1.18.0.log

[lexx-spb-ru]

I got crashed everytime I open folder which contains C/C++ files. C/C++ Extension v 1.17.5 IntelliSense and Indexing ... If any one has extra solution please help or can guide me for gathering more info that can have to fix this crash

@MArKy1998 , I suggest to collect and report Crash stacks, if you can't share code (see pinned comment in this issue for more info)

[rganascim]

Environment

OS and version: macOS 14.1.1 23B81 arm64 VS Code: 1.84.2 C/C++ extension: v1.18.2

Issue description:

With larger projects, the language server continuously crashes. It's crashing too fast, that I need an external script to collect the lldb info while the cpptools still executes.

Errors suddenly appeared 2 days ago when I open VSCode. I was using in the same project without any problems. I already did the intellisense cache clear, and even tried to unistall all extensions, reinstall visual studio, change the cpptools versions. But I'm always getting this crash.

crash_stack_cpptools_macos.txt

[comio]

Same error on 1.19.0. The logs look clean.

[MArKy1998]

I reinstall window - that is fixed You should try

On Sat, Nov 18, 2023 at 9:21 PM comio @.***> wrote:

Same error on 1.19.0. The logs look clean.

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode-cpptools/issues/10651#issuecomment-1817521859, or unsubscribe https://github.com/notifications/unsubscribe-auth/BADM33LH2A4TGN6F65WOMHLYFC753AVCNFSM6AAAAAAVVZBYGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGUZDCOBVHE . You are receiving this because you were mentioned.Message ID: @.***>

--

Trần Trung

Mobile App Development Department.

Vietnam Payment Solution Joint Stock Company (VNPAY)

Add: 7th Floor, 22 Lang Ha, Dong Da, Ha Noi | Email: @.*** @.***> | Skype: +84835201071 | Mobile: +84835201071 Website: www.vnpay.vn | www.vnpayqr.vn | www.vban.vn

[bobbrow]

Pasting the stack from @rganascim so we don't miss it.

* thread #9, stop reason = signal SIGABRT
  * frame #0: 0x00000001842b911c libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001842f0cc0 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x0000000184200a40 libsystem_c.dylib`abort + 180
    frame #3: 0x00000001842a86d8 libc++abi.dylib`abort_message + 132
    frame #4: 0x00000001842986a0 libc++abi.dylib`demangling_terminate_handler() + 52
    frame #5: 0x00000001842a7a9c libc++abi.dylib`std::__terminate(void (*)()) + 16
    frame #6: 0x00000001842a7a2c libc++abi.dylib`std::terminate() + 36
    frame #7: 0x00000001842aac5c libc++abi.dylib`__cxa_rethrow + 152
    frame #8: 0x0000000102d08580 cpptools`msvc::path_utf8_iterator::operator++() + 72
    frame #9: 0x00000001023665a4 cpptools`cpp_properties::parse_includes(std::__1::vector<include_path, std::__1::allocator<include_path>> const&, std::__1::vector<include_path, std::__1::allocator<include_path>>&, bool, std::__1::shared_ptr<browse_include_paths> const&) const + 4520
    frame #10: 0x00000001023600ac cpptools`cpp_properties::resolve_includes(compilation_args&) const + 144
    frame #11: 0x0000000102363d94 cpptools`cpp_properties::resolve_current_config(compilation_args&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, bool, bool) const + 1320
    frame #12: 0x00000001023630dc cpptools`cpp_properties::provide_args(char const*, bool) const + 2044
    frame #13: 0x00000001024b2bac cpptools`create_sync_work(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, char const*, unsigned long long, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool, bool, bool) + 1716
    frame #14: 0x00000001024b46d8 cpptools`create_async_work(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, char const*, unsigned long long, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool) + 100
    frame #15: 0x00000001024bb1f0 cpptools`std::__1::__function::__func<void thread_pool::enqueue<intellisense_client_factory::create_async(char const*, char const*, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool, std::__1::function<void (std::__1::vector<std::__1::shared_ptr<intellisense_client>, std::__1::allocator<std::__1::shared_ptr<intellisense_client>>>)>&&, std::__1::function<void ()>&&)::$_4, void>(intellisense_client_factory::create_async(char const*, char const*, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool, std::__1::function<void (std::__1::vector<std::__1::shared_ptr<intellisense_client>, std::__1::allocator<std::__1::shared_ptr<intellisense_client>>>)>&&, std::__1::function<void ()>&&)::$_4&&, std::__1::future<void>*)::'lambda'(), std::__1::allocator<void thread_pool::enqueue<intellisense_client_factory::create_async(char const*, char const*, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool, std::__1::function<void (std::__1::vector<std::__1::shared_ptr<intellisense_client>, std::__1::allocator<std::__1::shared_ptr<intellisense_client>>>)>&&, std::__1::function<void ()>&&)::$_4, void>(intellisense_client_factory::create_async(char const*, char const*, std::__1::shared_ptr<browse_engine> const&, std::__1::shared_ptr<cpp_properties> const&, bool, std::__1::function<void (std::__1::vector<std::__1::shared_ptr<intellisense_client>, std::__1::allocator<std::__1::shared_ptr<intellisense_client>>>)>&&, std::__1::function<void ()>&&)::$_4&&, std::__1::future<void>*)::'lambda'()>, void ()>::operator()() + 60
    frame #16: 0x00000001024eb944 cpptools`thread_pool::do_work(unsigned long) + 772
    frame #17: 0x0000000102d1c9a0 cpptools`msvc::thread_helper_t::thread_entry(void*) + 32
    frame #18: 0x00000001842f1034 libsystem_pthread.dylib`_pthread_start + 136

[sean-mcmanus]

@bobbrow This is already fixed in 1.19.0 -- https://github.com/microsoft/vscode-cpptools/issues/11674 .