Failed to read response from server: 20 while parsing document

[tanshihaj]

Type: LanguageService

I have an issue with language server. When I'm opening one file with vscode-cpptools enabled it seems that intellisense doesn't work and in c/c++ output I see following lines:

sending compilation args for /Users/zaripov-kamil/blah/plumbus/main.cpp
  include: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/include
  ...
  framework: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
  define: __llvm__=1
  ...
  other: --clang
  other: --clang_version=120000
  stdver: c++17
  intelliSenseMode: clang-x64
idle loop: reparsing the active document
Checking for syntax errors: file:///Users/zaripov-kamil/blah/plumbus/main.cpp
cpptools/getDocumentSymbols
cpptools/getCodeActions: file:///Users/zaripov-kamil/blah/plumbus/main.cpp (id: 9)
Queueing IntelliSense update for files in translation unit of: /Users/zaripov-kamil/blah/plumbus/main.cpp
Database safe to open
Failed to read response from server: 20
cpptools/finishUpdateSquiggles
Update IntelliSense time (sec): 9.442

I see suspicious Failed to read response from server: 20 but I don't know why client failed to read response.

Describe the bug

• OS and Version: macOS 10.15.7 (19H15)
• VS Code Version: 1.52.1 (Commit: ea3859d4ba2f3e577a159bc91e3074c5d85c0523)
• C/C++ Extension Version: v1.1.3
• Other extensions you installed (and if the issue persists after disabling them):
• Does this issue involve using SSH remote to run the extension on a remote machine?: no
• A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).

Steps to reproduce
Unfortunately I can't share code sample to reproduce error.

Expected behavior

Logs

Insert logs here.

Screenshots

Additional context

[sean-mcmanus]

Our IntelliSense process (cpptools-srv) is crashing. Are you able to somehow get a crash call stack? Otherwise, we may need an isolated repro.

We have a preview release with some crash fixes at https://github.com/microsoft/vscode-cpptools/releases/tag/1.2.0-preview you could try.

[tanshihaj]

Well I've checked ~/Library/Logs/DiagnosticReports/ on my macOS and I didn't see any crashes related with cppptools-srv (I can see crash reports of other crashed programs in this folder, I've tested it with cout << *nullptr; program). And I can't catch moment and attach debugger to the cppptools-srv after it starts but before it crashes. Do you have any tips how to debug cppptools-srv crash on macOS?

Version 1.20-preview is better (I can now follow by headers) but still can't follow symbols, I see following errors while trying to hover/follow symbols:

textDocument/definition: file:///Users/zaripov-kamil/blah/plumbus/main.cpp (id: 10)
IntelliSense process crash detected.
IntelliSense engine is not responding. Using the Tag Parser instead.

[sean-mcmanus]

Something sometimes suppresses Mac crashes getting logged to ~/Library/Logs/DiagnosticReports (we haven't figured out what causes the difference in behavior).

I don't know what you mean by a cout << *nullptr program -- that would crash your own program and not affect cpptools-srv.

cpptools-srv on Mac has a problem in that attaching a debugger may cause it to exit out -- however, 1.2.0-preview has a new IPC mechanism so I haven't checked if that issue still happens yet. Either way, it's relatively high on our TODO list to make it possible for users to attach a debugger to cpptools-srv possible, see #6151 .

Yeah, the new "IntelliSense process crash detected" message replaces the "Failed to read response" message.

[tanshihaj]

Well when I'm trying to connect debugger to the cpptools:

zaripov-kamil-x:~ zaripov-kamil$ lldb -p 26801
(lldb) process attach --pid 26801
error: attach failed: attach failed (Not allowed to attach to process.  Look in the console messages (Console.app), near the debugserver entries when the attached failed.  The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.)

errors from Console.app:

error: MachTask::TaskPortForProcessID task_for_pid failed: ::task_for_pid ( target_tport = 0x0103, pid = 26801, &task ) => err = 0x00000005 ((os/kern) failure)

It seems that macOS forbids to debug binaries, which signs doesn't contains com.apple.security.get-task-allow entitlement. (See more in https://apple.stackexchange.com/questions/409046/how-to-get-lldb-to-work-on-m1-big-sur)

Do you have sources of cpptool so I can add this entitlement and recompile it or can you provide me binary compiled with this entitlement?

It seems that it is some macOS specific issue since same plugin with same vscode version opening same source code on Linux machine works like a charm.

I don't know what you mean by a cout << *nullptr program -- that would crash your own program and not affect cpptools-srv.

I just want to say that in general crash reporting works on my system except cpptool crashes.

[sean-mcmanus]

vscode might be suppressing crash reporting of child processes.

Your original bug report said you were on mac 10.15.7. You're on 11.1 now? When I run "lldb -p" I don't get that error -- it stops in the debugger (but then the app exits out, which is a different issue we need to fix). Maybe my Mac is configured differently to get around that issue.

We'll try to find some way to get crash call stacks on Mac...

[tanshihaj]

Nope, I still use macOS 10.15.7 (Catalina)/ XCode Version 12.1 (12A7403)/lldb-1200.0.32.1.

When I run "lldb -p" I don't get that error

It seems that you trying to connect to the unsigned cpptools at all - maybe developer version. Unsigned binaries doesn't require com.apple.security.get-task-allow entitlement.

it stops in the debugger

Did you try to connect to the process without stopping process (more specifically sending command continue instantly after attaching using bash pipes)? Maybe it exists since VSCode kills it after timeout?

If you can give me unsigned version of cpptools maybe I can debug crash.

[sean-mcmanus]

No, I'm attaching to cpptools from 1.1.3 which has signed binaries -- after I use "continue" the process exits out due to an issue that we've fixed (#6151), afterwhich I can use "continue". I haven't fixed attaching to cpptools-srv yet (#6736).

Why do you believe an unsigned binary would enable debugging of the crash?

Also, I'm hitting an issue where I can't get VS Code to break into the debugger that I've been talking to @WardenGnaw about, but I don't hit that issue using lldb.

@Colengms @WardenGnaw Are you familiar with get-task-allow issue or why I'm not hitting this?