After some time all extension-related functions stop working with SIGFAULT (Linux)

[alxzh]

I have VSCode installed on OpenSUSE it is configured for C++. When I start the IDE it works as charm, but after some time all the functions stop working (auto-completion, formatting, etc.). I have no idea how to debug this to provide more information.

[sean-mcmanus]

What version of cpptools do you have? Is Microsoft.VSCode.Cpp.Extension.linux running? Is it using CPU? Is "Linux" red in the bottom right? Do you get a crash message? If you can attach a debugger to the .linux process and get a dmp that would be good. The only known bug where this could happen is after you change your files.exclude settings.

[alxzh]

Yep, my bad. So here is the info:

• VSCode version - 1.10.2
• plugin version - 0.10.5
• extension excutable is running in the beginning, but after some time when extension stops working Microsoft.VSCode.CPP.Extension.linux process disappears from process list.
• "Linux" is white in the bottom right all the time, even after extension died.
• It crashes silently without any crash messages.

During normal workflow I edit plain text files and C++ files. Sometimes several C++ files with the same names from different directories/projects.

And I actually found core dump. GDB says that it segfaulted here:
Core was generated by `/home/azhavnerchik/.vscode/extensions/ms-vscode.cpptools-0.10.5/bin/Microsoft.V'.
Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x0000000000a7d37c in microsoft::vc::utf32_char_to_utf8(char32_t, char*) ()
[Current thread is 1 (Thread 0x7f8452698700 (LWP 7173))]
(gdb) bt
#0  0x0000000000a7d37c in microsoft::vc::utf32_char_to_utf8(char32_t, char*) ()
#1  0x0000000000a754f5 in microsoft::vc::to_lower_utf8(char*) ()
#2  0x00000000005ea958 in code_store::a_connection::ordinal_case_func_utf8(sqlite3_context*, int, Mem**) ()
#3  0x0000000000640f80 in sqlite3VdbeExec ()
#4  0x0000000000611441 in sqlite3_step ()
#5  0x00000000005e2060 in code_store::a_statement::step(bool) ()
#6  0x00000000005f3a6f in code_store::a_results_statement<code_store::a_full_code_items_set, code_store::schema::code_items::a_read_statement, code_store::full_code_items_set>::move_next() ()
#7  0x000000000059d5ee in browse_engine::query_completion(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, position const&, std::__1::vector<code_store::a_full_code_item_record, std::__1::allocator<code_store::a_full_code_item_record> >&, bool) ()
#8  0x000000000058970c in auto_complete::populate_completion_from_store(vscode::TextDocumentPositionParams, vscode::ext::optional<vscode::Range>, std::__1::vector<vscode::CompletionItem, std::__1::allocator<vscode::CompletionItem> >&, bool&) ()
#9  0x000000000058939f in auto_complete::handle_completion(vscode::TextDocumentPositionParams, bool&) ()
#10 0x000000000055408c in message_handler::textDocument_completion(vscode::TextDocumentPositionParams) ()
#11 0x0000000000545d5f in vscode::handler_base<message_handler>::dispatch(vscode::vscode_client_message&&, vscode::vscode_server_message&) ()
#12 0x0000000000543281 in vscode::handler_base<message_handler>::handle_message(vscode::vscode_client_message&&) ()
#13 0x00000000005430ed in vscode::handler_base<message_handler>::main_loop()::{lambda()#1}::operator()() const ()
#14 0x000000000054306d in void* std::__1::__thread_proxy<std::__1::tuple<vscode::handler_base<message_handler>::main_loop()::{lambda()#1}> >(std::__1::tuple<vscode::handler_base<message_handler>::main_loop()::{lambda()#1}>) ()
#15 0x00007f845506d537 in start_thread (arg=0x7f8452698700) at pthread_create.c:456
#16 0x00007f8454dae04f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

[sean-mcmanus]

Thanks a lot for the call stack. The bug repros when UTF8 chars > 1 byte are used. We fixed a bunch of bugs in the scenario, but this is one we missed. What is the encoding of the file? If it's not UTF8, we probably have additional problems. Are you able to determine which characters are causing the crash so I can verify our fix works? Our code assumes the input is a UTF8 string, then converts it to UTF32, lowercases it, and then converts the UTF32 to UTF8. So I have a fix for one bug with our code which always wrote in 4 byte increments even if the source string was < 4 bytes long, but without a repro, I'm not sure if there are additional bugs.

[alxzh]

The file supposed to be in UTF8. I don't know what character triggers it.

…

On Wed, Apr 5, 2017, 12:36 Sean McManus ***@***.***> wrote: Thanks a lot for the call stack. The bug repros when UTF8 chars > 1 byte are used. We fixed a bunch of bugs in the scenario, but this is one we missed. What is the encoding of the file? Are you able to determine which characters are causing the crash so I can verify our fix works? Our code assumes the input is a UTF8 string, then converts it to UTF32, lowercases it, and then converts the UTF32 to UTF8. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#608 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVSb2orhF6d9nJWaFBAxwKgqQCb6NtBks5rs-0egaJpZM4MzvlL> .

[alxzh]

Any ETA on a fix? Right now extension is pretty much unusable because it fails after a few minutes every time. Or probably there is a way to get experimental version?

[sean-mcmanus]

We're planning to release an update "soon" which may have the fix. Is changing the autocomplete setting to "Disabled" a work around? Does the bug only repro when editing and only with autocomplete or is there another repro scenario? The current fix prevents the crash from the call stack you provided (in to_lower_utf8 and to_upper_utf8), but I'm worried that the root cause may be a document corruption that is creating invalid UTF8 characters. Getting a more solid repro would help. Are you able to get a repro with an open source project with only 1 byte UTF8 characters? If you change the addWorkspaceRootToIncludePath setting to false and delete your .browse.vc.db (or change the databaseFilename property in c_cpp_properties.json) then it should limit the amount of files that are processed, potentially preventing the bad UTF8 characters from entering the database.

[bobbrow]

We made some fixes in this area and published them with v.0.11.0. Can you try again and see if the experience has improved? Thanks!

[vulptex]

Hi,

i can still see those segfaults after several seconds. I do embedded c/c++ development. Simply get the esp32 idf sdk from espressif and do some hacking :-).

It will crash after some seconds and renders the whole autocompletion useless ;-/.

Given:

OS:
Linux x_solus 4.9.18-10.lts #1 SMP Sun Mar 26 15:44:05 UTC 2017 x86_64 GNU/Linux

vscode:

Version 1.13.1
Commit 19222cdc84ce72202478ba1cec5cb557b71163de
Date 2017-05-16T08:14:27.220Z
Shell 1.6.6
Renderer 56.0.2924.87
Node 7.4.0

cpptools:
Version 0.12.0: June 26, 2017

Settings:

"C_Cpp.formatting": "Disabled",
"C_Cpp.clang_format_fallbackStyle": "Google", 
"C_Cpp.intelliSenseEngine": "Default",
"C_Cpp.intelliSenseEngineFallback": "Enabled",
"C_Cpp.autocomplete": "Default",

Then:

[  304.302253] Microsoft.VSCod[5390]: segfault at 1c ip 000000000077fb46 sp 00007fef213bb0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  306.916462] Microsoft.VSCod[5471]: segfault at 1c ip 000000000077fb46 sp 00007f46a77fb0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  312.899043] Microsoft.VSCod[5585]: segfault at 1c ip 000000000077fb46 sp 00007f8ed37fb0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  327.468995] Microsoft.VSCod[5890]: segfault at 1c ip 000000000077fb46 sp 00007f7df5ff80d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  334.074488] Microsoft.VSCod[6014]: segfault at 1c ip 000000000077fb46 sp 00007f1223ffc0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  341.354442] Microsoft.VSCod[6227]: segfault at 1c ip 000000000077fb46 sp 00007f2ae569f0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  345.980402] Microsoft.VSCod[6257]: segfault at 1c ip 000000000077fb46 sp 00007fab70b720d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  356.505570] Microsoft.VSCod[6478]: segfault at 1c ip 000000000077fb46 sp 00007f383f7fb0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  358.260843] Microsoft.VSCod[6595]: segfault at 1c ip 000000000077fb46 sp 00007f77e3ffc0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  377.829633] Microsoft.VSCod[6909]: segfault at 1c ip 000000000077fb46 sp 00007f4ea2ffa0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  401.543459] Microsoft.VSCod[7418]: segfault at 1c ip 000000000077fb46 sp 00007f2881ff80d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  416.306395] Microsoft.VSCod[7772]: segfault at 1c ip 000000000077fb46 sp 00007fe37fffc0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  439.313047] Microsoft.VSCod[8276]: segfault at 1c ip 000000000077fb46 sp 00007f44fe7f90d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  452.213516] Microsoft.VSCod[8606]: segfault at 1c ip 000000000077fb46 sp 00007f96e17f70d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  459.970809] Microsoft.VSCod[8642]: segfault at 1c ip 000000000077fb46 sp 00007fdd1b7fb0d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]
[  528.889207] Microsoft.VSCod[9832]: segfault at 1c ip 000000000077fb46 sp 00007fc18e7f90d0 error 4 in Microsoft.VSCode.CPP.IntelliSense.Msvc.linux[400000+68a000]

[sean-mcmanus]

@9cubes We need a repro, call stack, core dmp, etc.. Our pending update does have some crash fixes, but I need to see the call stack to tell if it's a fixed crash or not.

[jamesone]

Just adding this here: This still happens on Version 1.9.0 (1.9.0)
macOS: 10.12.6

[sean-mcmanus]

@jamesone There are many possible root causes of the crash you are experiencing. Please file a new bug and let us know at least the top few lines of the crashing thread shown in the crash log at ~/Library/Logs/DiagnosticReports . Any other info such as a way to repro the crash would help.

[michelleangela]

Closing this issue due to long inactivity. If you update to the latest version of the C/C++ extension and your issue still persists, please re-open the issue and reply with additional information that can help us investigate the issue.