IntelliSense crashes with seastar/src/util/file.cc

[avikivity]

Type: LanguageService

Describe the bug

• OS and Version: Fedora 32
• VS Code Version: code-1.48.0-1597305152.el7.x86_64
• C/C++ Extension Version: ms-vscode.cpptools-0.30.0-insiders2
• Other extensions you installed (and if the issue persists after disabling them): none
• 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). cpptools-srv crashes; single project, 650k sloc

Steps to reproduce

1. I suppose trying to setup vscode to work with https://github.com/scylladb/scylla.git will reproduce this (I see this on two machines) but it's probably not easy. I can upload a core dump if it's helpful.

Expected behavior

No crash, everything works swimmingly, world peace

Logs

Failed to read response from server: 20

Screenshots

Additional context

Backtrace:

(gdb) bt
#0  0x00000000008f7c9b in add_symbol_to_overload_list(a_symbol*, a_symbol*, int, a_namespace*) ()
#1  0x00000000008f81c4 in enter_overloaded_symbol(unsigned char, a_symbol_locator*, int, a_symbol*, a_symbol**) ()
#2  0x0000000000703f77 in decl_function_template(a_symbol_locator*, a_func_info_block*, a_symbol**, a_tmpl_decl_state*) ()
#3  0x000000000092e0c9 in template_declaration(a_tmpl_decl_state*) ()
#4  0x0000000000928b51 in template_or_specialization_declaration_full(a_tmpl_decl_state*, int, a_decl_parse_state*) ()
#5  0x000000000092ee29 in template_or_specialization_declaration(a_token_kind*, int, a_source_position*, int, a_decl_parse_state*) ()
#6  0x0000000000934166 in template_directive_or_declaration(a_token_kind*, int, a_source_position*) ()
#7  0x000000000070d7f0 in scan_nonmember_declaration(a_decl_parse_state*, a_source_range*) ()
#8  0x0000000000715c49 in namespace_declaration(a_token_kind*, int, int, a_source_position*, a_symbol**) ()
#9  0x000000000070ded3 in scan_nonmember_declaration(a_decl_parse_state*, a_source_range*) ()
#10 0x00000000007137d9 in declaration(int, int, int, int, a_param_id*, a_source_range*) ()
#11 0x0000000000605d99 in compile_fragment((anonymous namespace)::a_fragment_buffer const&, a_canonicalized_file_name, msvc::strong_typedef_t<msvc::offset_traits>, msvc::strong_typedef_t<msvc::offset_traits>, msvc::strong_typedef_t<msvc::offset_traits>, bool, a_declaration_context const&, a_region_scope_info const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool, bool, bool, bool*) ()
#12 0x0000000000603497 in before_tu_wrapup() ()
#13 0x0000000000951c99 in process_translation_unit(char const*, int, an_exported_template_file*) ()
#14 0x00000000006733f7 in cfe_main(int, char**) ()
#15 0x00000000009727f6 in cfe_main_exception_handler(int, char**) ()
#16 0x0000000000673506 in edg_main(int, char**) ()
#17 0x000000000096cd86 in edge_compiler_main(int, char const**) ()
#18 0x0000000000603b77 in preparse(int, char const**, a_scout_store*, edge::translation_unit*) ()
#19 0x00000000005cec0f in a_compiler_thread::compiler_thread_routine(a_compiler_thread*) ()
#20 0x0000000000a8f990 in execute_native_thread_routine ()
#21 0x00007f3e545ae432 in start_thread () from /lib64/libpthread.so.0
#22 0x00007f3e544dc913 in clone () from /lib64/libc.so.6

Disassembly around the crash:

   0x00000000008f7c29 <+665>:	shl    $0x20,%rcx
   0x00000000008f7c2d <+669>:	or     %rax,%rcx
   0x00000000008f7c30 <+672>:	test   $0x20000,%ecx
   0x00000000008f7c36 <+678>:	jne    0x8f7cc3 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+819>
   0x00000000008f7c3c <+684>:	test   $0x1000,%ecx
   0x00000000008f7c42 <+690>:	jne    0x8f7c5d <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+717>
   0x00000000008f7c44 <+692>:	testb  $0x1,0xa8(%r14)
   0x00000000008f7c4c <+700>:	jne    0x8f7c6c <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+732>
   0x00000000008f7c4e <+702>:	mov    0x18(%rbp),%rax
   0x00000000008f7c52 <+706>:	cmp    %r12,%rax
   0x00000000008f7c55 <+709>:	jne    0x8f7c75 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+741>
   0x00000000008f7c57 <+711>:	add    $0x18,%rbp
   0x00000000008f7c5b <+715>:	jmp    0x8f7c9b <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+779>
   0x00000000008f7c5d <+717>:	mov    0x28(%rbp),%rax
   0x00000000008f7c61 <+721>:	cmp    %r12,%rax
   0x00000000008f7c64 <+724>:	jne    0x8f7c75 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+741>
   0x00000000008f7c66 <+726>:	add    $0x28,%rbp
   0x00000000008f7c6a <+730>:	jmp    0x8f7c9b <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+779>
   0x00000000008f7c6c <+732>:	mov    0x20(%rbp),%rax
   0x00000000008f7c70 <+736>:	cmp    %r12,%rax
   0x00000000008f7c73 <+739>:	je     0x8f7c97 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+775>
   0x00000000008f7c75 <+741>:	cmp    %r12,%rax
   0x00000000008f7c78 <+744>:	je     0x8f7c9f <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+783>
   0x00000000008f7c7a <+746>:	nopw   0x0(%rax,%rax,1)
   0x00000000008f7c80 <+752>:	mov    %rax,%rbp
   0x00000000008f7c83 <+755>:	test   %rax,%rax
   0x00000000008f7c86 <+758>:	je     0x8f7c91 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+769>
   0x00000000008f7c88 <+760>:	mov    0x8(%rbp),%rax
   0x00000000008f7c8c <+764>:	cmp    %r12,%rax
   0x00000000008f7c8f <+767>:	jne    0x8f7c80 <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+752>
   0x00000000008f7c91 <+769>:	add    $0x8,%rbp
   0x00000000008f7c95 <+773>:	jmp    0x8f7c9b <_Z27add_symbol_to_overload_listP8a_symbolS0_iP11a_namespace+779>
   0x00000000008f7c97 <+775>:	add    $0x20,%rbp
=> 0x00000000008f7c9b <+779>:	mov    %rbx,0x0(%rbp)
   0x00000000008f7c9f <+783>:	mov    0x8(%r12),%rax
   0x00000000008f7ca4 <+788>:	mov    %rax,0x8(%rbx)
   0x00000000008f7ca8 <+792>:	movq   $0x0,0x8(%r12)
   0x00000000008f7cb1 <+801>:	mov    0x59(%r12),%eax
   0x00000000008f7cb6 <+806>:	movzbl 0x5d(%r12),%ecx

Registers:

(gdb) info registers 
rax            0x0                 0
rbx            0x7f294ea65198      139815389909400
rcx            0x800040            8388672
rdx            0x0                 0
rsi            0x0                 0
rdi            0x80                128
rbp            0x8                 0x8
rsp            0x7f3e4b7fc030      0x7f3e4b7fc030
r8             0x7f3e4b7fc120      139905531363616
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x7f294ea29ea8      139815389666984
r13            0x0                 0
r14            0x7f2938896c38      139815018916920
r15            0x7f294ea64f60      139815389908832
rip            0x8f7c9b            0x8f7c9b <add_symbol_to_overload_list(a_symbol*, a_symbol*, int, a_namespace*)+779>
eflags         0x10202             [ IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0

[sean-mcmanus]

What file are you opening in that project?

[avikivity]

I don't know which one I opened when I saw the crash. I did see several crashes, but afterwards the language server shuts down and reverts to the tag parser, and I don't know how to get it started back (I tried resetting the database and restarting the extension host).

I'm happy to upload a core dump somewhere if it helps.

[avikivity]

btw, I also recommend including debug symbols with the cpp extension (of the extension itself). Many developers will not be able to resist the urge to debug it themselves, and you will get higher quality reports.

[sean-mcmanus]

The debug symbols makes the binary very large and is unlikely to be usable by external people for debugging/diagnostics.

I can try to locate the file that is reproing the crash, but if you can enable debug logging (https://code.visualstudio.com/docs/cpp/enable-logging-cpp) and then search for a "Failed to read response from server" message and then look for which file was being processed that would help get a repro.

[avikivity]

I already had logging enabled, and found this in the logs:

Checking for syntax errors: file:///home/avi/scylla/seastar/include/seastar/core/future.hh
Queueing IntelliSense update for files in translation unit of: /home/avi/scylla/db/config.cc
Queueing IntelliSense update for files in translation unit of: /home/avi/scylla/seastar/src/util/file.cc
cpptools/activeDocumentChange: file:///home/avi/scylla/seastar/include/seastar/core/future.hh
cpptools/textEditorSelectionChange
cpptools/getDocumentSymbols: file:///home/avi/scylla/seastar/include/seastar/core/future.hh (id: 55)
cpptools/textEditorSelectionChange
cpptools/textEditorSelectionChange
cpptools/getDocumentSymbols
cpptools/getSemanticTokens: file:///home/avi/scylla/seastar/include/seastar/core/future.hh (id: 56)
cpptools/getFoldingRanges: file:///home/avi/scylla/seastar/include/seastar/core/future.hh (id: 57)
cpptools/getCodeActions: file:///home/avi/scylla/seastar/include/seastar/core/future.hh (id: 58)
idle loop: reparsing the active document
Checking for syntax errors: file:///home/avi/scylla/seastar/include/seastar/core/future.hh
Queueing IntelliSense update for files in translation unit of: /home/avi/scylla/db/config.cc
Queueing IntelliSense update for files in translation unit of: /home/avi/scylla/seastar/src/util/file.cc
Failed to read response from server: 22

future.hh et al are in a submodule, so run git submodule update --init --recursive to populate the submodules.

My configuration:

{
    "C_Cpp.default.includePath": [
        "/home/avi/scylla/",
        "/home/avi/scylla/seastar/include",
        "/home/avi/scylla/build/dev/seastar/gen/include",
        "/home/avi/scylla/abseil",
        "/home/avi/scylla/build/dev/gen"
    ],
    "C_Cpp.default.intelliSenseMode": "gcc-x64",
    "C_Cpp.intelliSenseEngineFallback": "Disabled",
    "C_Cpp.default.defines": [
        "SEASTAR_API_LEVEL=4",
        "__cpp_concepts=201907L"
    ],
    "C_Cpp.loggingLevel": "Debug",
    "C_Cpp.default.cppStandard": "c++20",
    "C_Cpp.default.cStandard": "c11",
    "C_Cpp.default.compilerPath": "/usr/bin/g++"
}

[avikivity]

(gcc 10.2)

[sean-mcmanus]

Thanks for the info. I reproed the crashes. Good news is the crashes are fixed with our pending 0.30.0-insiders3, which we'll try to release this week, but it might get delayed. Some of the crashes were related to #5897 .

[avikivity]

Great, thanks. Any tips on how to get code to start using the language server again? After a few crashes it backs off and doesn't want to talk to it again.

[sean-mcmanus]

I would switch back to 0.29.0 until we can release 0.30.0-insiders3 (or switch to gcc 10.0, but that is probably hard to do).

[sean-mcmanus]

The wide spread crashing has been fixed with our pending 0.30.0-insiders3 (e.g. config.cc), but file.cc is still crashing, so we're still investigating that.

[avikivity]

I would switch back to 0.29.0 until we can release 0.30.0-insiders3 (or switch to gcc 10.0, but that is probably hard to do).

Thanks, I'll do that.

[sean-mcmanus]

I've reported VS bug https://developercommunity.visualstudio.com/content/problem/1157735/c-intellisense-gives-incorrect-squiggles-and-crash.html .

[sean-mcmanus]

We fixed the 0.30.0-insiders2 regression crashes with https://github.com/microsoft/vscode-cpptools/releases/tag/0.30.0-insiders3 , so you should be able to update to that (it should have some better C++20 support). The file.cc crash repros with 0.29.0 still. Let me know if you notice IntelliSense crashing with other files, because those could be different crashes.

[avikivity]

Switched, from a quick look-around things work well. Thanks a lot.