crashes on startup

[m76589]

Type: Bug

using latest version 1.19.9 and tried with 1.18.5.
C++ crashes repeatedly on startup and is therefore diabled by vs code.
This report was generated using the bisect so I hope it gives the information required to fix.

Extension version: 1.18.5
VS Code version: Code 1.88.0 (Universal) (5c3e652f63e798a5ac2f31ffd0d863669328dc4c, 2024-04-03T13:28:18.899Z)
OS version: Darwin x64 21.6.0
Modes:

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz (4 x 2900)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	6, 5, 5
Memory (System)	8.00GB (0.37GB free)
Process Argv	--crash-reporter-id 39243ef1-8df8-4cca-bf3e-9ae04af16394
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
2e7ec940:31000449
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
d6fi2104:30959263
cppperfnew:31000557
d34g3935:30971562
fegfb526:30981948
bg6jg535:30979843
ccp2r3:30993541
dsvsc020:30976470
pythonait:31006305
gee8j676:31009558
chatpanelc:31018788
dsvsc021:30996838
bdiig495:31013172
pythoncenvpt:31022790

[browntarik]

Could you please provide more information about what is causing the crash? Does it happen whenever you open any .cpp file? Could you provide a copy of your c_cpp_properties.json file? This should be in the .vscode folder

[m76589]

Hi thanks for replying. It was occurring whenever I opened VS code.

I have some folders in the workspace that was being opened when i opened vs code - raspberry pi/pico sdk etc but none with my own C++. (For context I'm just getting started with this dev environment on the mac and with the pi/pico.)

There's no file by that name in .vscode in my home folder:

$ rglob **/*cpp*.json
extensions/ms-vscode.cmake-tools-1.17.17/dist/src/cpptools.nls.metadata.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/cppdbg.ad7Engine.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/debugAdapters/bin/cppdbg.ad7Engine.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/cs/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/de/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/es/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/fr/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/it/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/ja/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/ko/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/pl/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/pt-br/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/ru/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/tr/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/zh-cn/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/schema/zh-tw/c_cpp_properties.schema.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/LanguageServer/cppBuildTaskProvider.nls.metadata.json
extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/cppTools.nls.metadata.json
extensions/ms-vscode.cpptools-themes-2.0.0/themes/cpptools_dark_vs.json
extensions/ms-vscode.cpptools-themes-2.0.0/themes/cpptools_dark_vs_new.json
extensions/ms-vscode.cpptools-themes-2.0.0/themes/cpptools_light_vs.json
extensions/ms-vscode.cpptools-themes-2.0.0/themes/cpptools_light_vs_new.json

[m76589]

maybe this file?
c_cpp_properties.schema.json
c_cpp_properties.schema.json

[sean-mcmanus]

@m76589 The c_cpp_properties.json file would exist in your workspace folder's .vscode folder, but it won't exist unless you generated it via a command like C/C++: Edit Configuration. Without it, it uses defaults.

With 1.20.1, we've added crash call stack logging if you check the Help->Toggle Developer Tools->Console.

Otherwise, can you set C_Cpp.loggingLevel to "Debug" and check the "C/C++" pane logging to see what output occurs before the crash? Typically a crash restart will generate another "initialize" message.

[m76589]

I've split my initial workspace into two smaller ones and the issue seems not to occur (only tested briefly).

From the debug info in the console there's some information that shows before the crash about something being used before initialized. The crashes occur when i open the workspace.

[ms-vscode.cpptools]Attempting to use languageClient before initialized
$onExtensionRuntimeError @ mainThreadExtensionService.ts:81
S @ rpcProtocol.ts:458
Q @ rpcProtocol.ts:443
M @ rpcProtocol.ts:373
L @ rpcProtocol.ts:299
(anonymous) @ rpcProtocol.ts:161
y @ event.ts:1156
fire @ event.ts:1187
fire @ ipc.net.ts:650
q.onmessage @ localProcessExtensionHost.ts:376
mainThreadExtensionService.ts:82 Error: Attempting to use languageClient before initialized
	at get languageClient [as languageClient] (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:49535:19)
	at DefaultClient.onDidChangeVisibleTextEditors (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:50263:20)
	at ClientCollection.recreateClients (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:52278:34)
	at Object.closed (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:50139:50)
	at LanguageClient.handleConnectionClosed (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:70439:72)
	at LanguageClient.handleConnectionClosed (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:79219:22)
	at closeHandler (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:70417:18)
	at CallbackList.invoke (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:67219:39)
	at Emitter.fire (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:67281:36)
	at closeHandler (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:66234:26)
	at CallbackList.invoke (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:67219:39)
	at Emitter.fire (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:67281:36)
	at StreamMessageWriter.fireClose (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:68151:27)
	at Socket.<anonymous> (/Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/dist/src/main.js:68183:42)
	at Socket.emit (node:events:517:28)
	at Pipe.<anonymous> (node:net:350:12)

[sean-mcmanus]

@m76589 Can you try with 1.20.2 (pre-release)? It may be fixed in there or the crash call stack may be shown in the Console tab after using the 'Toggle Developer Tools' command.

[m76589]

Ah. I see. Will do.

[sean-mcmanus]

@m76589 Also, I think Attempting to use languageClient before initialized is just a symptom of the cpptools crash. Were you able to get any C/C++ logging to show up?

Also, if you don't get any logging, can check if you have /Users/mm/.vscode/extensions/ms-vscode.cpptools-1.19.9-darwin-x64/bin/cpptools (or whatever the version is) and the file is runnable?

[m76589]

Hi Sean
Thank you for your help. I think these are the things you have asked for:

Crash call stack:

5workbench.desktop.main.js:sourcemap:152 [Extension Host] Crash call stack:
cpptools.txt
SIGSEGV
_sigtramp + 29
…
_ZNSt3__16__sortIRZN16cpptools_context10initializeEO23CppInitializationParamsE4 + 608
cpptools_context::initialize(CppInitializationParams&&) + 3496
_ZNSt3__110__function6__funcIZN11lsp_manager16register_requestI23CppInitializationParamsvZN16cpptools_contextC1EvE4 + 526
_ZN16thread_manager_t10queue_itemIZN11lsp_manager11deploy_taskERKN11thread_safeINS1_5stateENSt3__115recursive_mutexEE11safe_objectIS3_EEibE4 + 184
thread_manager_t::do_work(unsigned long) + 592
msvc::thread_helper_t::thread_entry(void*) + 20

C/C++ Logging:

loggingLevel: Debug
LSP: (received) cpptools/preinitialize (id: 1)
LSP: (invoked) cpptools/preinitialize (id: 1)
LSP: Sending response (id: 1)
LSP: (received) cpptools/initialize (id: 2)
LSP: (invoked) cpptools/initialize (id: 2)
cpptools version (TypeScript): 1.20.2
cpptools version (native): 1.20.2.0
Autocomplete is enabled.
Error squiggles are enabled if all header dependencies are resolved.
LSP: (received) cpptools/preinitialize (id: 1)
LSP: (invoked) cpptools/preinitialize (id: 1)
LSP: Sending response (id: 1)
LSP: (received) cpptools/initialize (id: 2)
LSP: (received) cpptools/preinitialize (id: 1)
LSP: (invoked) cpptools/preinitialize (id: 1)
LSP: Sending response (id: 1)
LSP: (received) cpptools/initialize (id: 2)
LSP: (received) cpptools/preinitialize (id: 1)
LSP: (invoked) cpptools/preinitialize (id: 1)
LSP: Sending response (id: 1)
LSP: (received) cpptools/initialize (id: 2)
LSP: (received) cpptools/preinitialize (id: 1)
LSP: (invoked) cpptools/preinitialize (id: 1)
LSP: Sending response (id: 1)
LSP: (received) cpptools/initialize (id: 2)

[m76589]

above updated due to copy-paste error.

[Colengms]

Hi @m76589 . Did your repro involve multiple workspace folders in a multi-root workspace that may have resolved to the same folder, due to a symbolic link in the file system, or some other reason why multiple paths wind up referring to the same folder? We believe we've identified a problem, but it would seem specific to multiple workspace folders in a workspace resolving to the same path. If that is not your scenario, there may be more for us to investigate.

[m76589]

Yes - I have/had two folders that were "added to workspace" that were sub folders of another top level workspace folder.
However I didn't check whether there were any sym links in the folders. They were raspberry pi pico examples from github - so it's possible.
In general I add subfolders to the workspace a lot, due to the way folders open on the left when also opening files.

[Colengms]

Hi @m76589 . To clarify, the issue we've identified is specific to exactly the same 'workspace folder' being present multiple times in a multi-root workspace, at the root level. You would see exactly the same contents in both (or all such) workspace folders. Normally, it's not possible to add the same folder to a multi-root workspace twice, though VS Code does not appear to resolve symbolic links and can allow this to happen if the paths differ due to containing a symbolic link. If you can confirm whether or not this scenario is indeed what occurred in your repro, that would help us determine if we've addressed the issue or not.

[m76589]

hi. Thanks for looking into this. Unfortunately I'm not with my laptop for two weeks now. If you want to try to reproduce... The folders i had open in the workspace were github repos for getting started with raspberry pi pico development. These were, from memory: pico-sdk, pico-extras, pico-examples, and pimoroni-pico. I had two of the sub folders open too: blink, helloword. That might suffice.

[sean-mcmanus]

@m76589 We think this is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/v1.20.3 , although we weren't able to repro your exact scenario so it's possible there could be another failure after the fix we made.