vballworld
commented
4 years ago Perhaps related, but the newest release seems to freeze on my C++ repo all the time.
Closed Yanpas closed 4 years ago
vballworld
commented
4 years ago Perhaps related, but the newest release seems to freeze on my C++ repo all the time.
deepak1556
commented
4 years ago @Yanpas how do things look when you run with --disable-extensions ?
@vballworld are you also using the ccls extension ? can you try with --disable-extensions ?
Yanpas
commented
4 years ago Can't reproduce, for me it only happened 3 times (almost in a row). According to gdb stack trace I bet it's regex-killer (DOS) from cpp grammar. https://github.com/jeff-hykin/cpp-textmate-grammar
Yanpas
commented
4 years ago Do you know how to inspect electron's app memory dump? Specifically getting v8 stack traces. AFAIK chromium is able to hold several virtual machines in one process. That would help in future.
deepak1556
commented
4 years ago @Yanpas can you raise an issue with that extension if you think the crash originates from there.
Do you know how to inspect electron's app memory dump? Specifically getting v8 stack traces
You can use https://github.com/nodejs/llnode for it
Yanpas
commented
4 years ago I doubt that it's extension fault cause I see main gui process hanging inside some regexp code. ccls is just a language server, with semantic coloring is disabled that didn't receive any updates for a long time. I'll try to get some steps to reproduce, currently playing with that file.
Yanpas
commented
4 years ago llnode didn't help, maybe there is no debug symbols in binaries. Here is a snippet which I was editing and got vscode hanged:
virtual void InsertDocument(const pugi::xml_node& src, const DocUid& uid) override {
auto dnode_it = dnodes_.find(uid.position);
if (dnode_it == dnodes_.end()) {
auto dnode = result_dl_.append_child("D");
dnode.append_attribute("position").set_value(uid.position);
dnode_it = dnodes_.insert({uid.position, {dnode, {}}}).first;
}
auto& [dnode, subnodes] = *dnode_it;
if (subnodes.)
}last lines of /home/yan/.config/Code/logs/20200310T183724/renderer8.log ( the process started at 20:11 )
[2020-03-12 18:57:03.731] [renderer8] [warning] UNRESPONSIVE extension host, 'johnstoncode.svn-scm' took 77% of 315.646ms, saved PROFILE here: '/tmp/exthost-7345b9.cpuprofile' [{"id":"ccls-project.ccls","total":320,"percentage":0},{"id":"gc","total":3042,"percentage":1},{"id":"johnstoncode.svn-scm","total":244486,"percentage":77},{"id":"redhat.java","total":164,"percentage":0},{"id":"self","total":67526,"percentage":21}]
[2020-03-12 18:57:13.224] [renderer8] [warning] UNRESPONSIVE extension host, 'johnstoncode.svn-scm' took 96% of 3904ms, saved PROFILE here: '/tmp/exthost-a30e1f.cpuprofile' [{"id":"ccls-project.ccls","total":641,"percentage":0},{"id":"eamodio.gitlens","total":314,"percentage":0},{"id":"gc","total":75056,"percentage":2},{"id":"johnstoncode.svn-scm","total":3756410,"percentage":96},{"id":"program","total":5620,"percentage":0},{"id":"redhat.java","total":1867,"percentage":0},{"id":"self","total":42995,"percentage":1}]
[2020-03-12 20:11:59.576] [renderer8] [error] not indexed: Error: not indexed
at handleResponse (/home/yan/.vscode/extensions/ccls-project.ccls-0.1.28/node_modules/vscode-jsonrpc/lib/main.js:436:48)
at processMessageQueue (/home/yan/.vscode/extensions/ccls-project.ccls-0.1.28/node_modules/vscode-jsonrpc/lib/main.js:263:17)
at Immediate.<anonymous> (/home/yan/.vscode/extensions/ccls-project.ccls-0.1.28/node_modules/vscode-jsonrpc/lib/main.js:247:13)
at processImmediate (internal/timers.js:439:21)
[2020-03-12 20:12:11.799] [renderer8] [warning] [File Watcher (chokidar)] Error: ELOOP: too many symbolic links encountered, stat '/home/yan/ssd/trunk_co2/projects/hadoop_tools/tests/qddb2/bin/bin'
The line at which regexp is working:
#0 0x00007fc15b993fb7 in left_adjust_char_head ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#1 0x00007fc15b98499e in match_at ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#2 0x00007fc15b988872 in onig_search ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#3 0x00007fc15b96fb59 in OnigRegExp::Search(char const*, unsigned long, unsigned long) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#4 0x00007fc15b96fca2 in OnigRegExp::Search(OnigString*, int) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#5 0x00007fc15b9738a2 in OnigSearcher::Search(OnigString*, int) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#6 0x00007fc15b9712f1 in OnigScanner::FindNextMatchSync(OnigString*, v8::Local<v8::Number>) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#7 0x00007fc15b9715d4 in OnigScanner::FindNextMatchSync(Nan::FunctionCallbackInfo<v8::Value> const&) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#8 0x00007fc15b970042 in Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) ()
at /usr/share/code/resources/app/node_modules.asar.unpacked/oniguruma/build/Release/onig_scanner.node
#9 0x00005649359becac in ()
#10 0x000168e900000001 in ()
#11 0x000019b96092f060 in ()
#12 0x0000000000000001 in ()
#13 0x00000000c1114a90 in ()
#14 0x0000006000000001 in ()
#15 0x000019b95e7be000 in ()
#16 0x000000000000000a in ()
#17 0x000024c0303004b1 in ()
#18 0x0000000000000000 in ()
(gdb) info registers
rax 0x19b965e130a0 28284068901024
rbx 0x19b965e130a1 28284068901025
rcx 0x7fc15b993fa0 140468442185632
rdx 0x40 64
rsi 0x19b965e130a0 28284068901024
rdi 0x19b965e12fb0 28284068900784
rbp 0x7fffc11124f0 0x7fffc11124f0
rsp 0x7fffc11124f0 0x7fffc11124f0
r8 0xcccccccccccccccd -3689348814741910323
r9 0x19b95f7cc000 28283961655296
r10 0x1 1
r11 0x19b95f14b5b3 28283954836915
r12 0x19b965e130a7 28284068901031
r13 0x19b95f14b5bb 28283954836923
r14 0x7fffc11127d0 140736432515024
r15 0x7fffc1112598 140736432514456
rip 0x7fc15b993fb7 0x7fc15b993fb7 <left_adjust_char_head+23>
eflags 0xa87 [ CF PF SF IF OF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/s 0x19b965e12fb0
0x19b965e12fb0: "std::_Rb_tree_iterator<std::pair<const long, std::pair<pugi::xml_node, std::map<std::basic_string<char>, pugi::xml_node, std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_"...
(gdb) cont
Continuing.
Thread 1 "code" received signal SIGSTOP, Stopped (signal).
0x00007fc15b98450b in match_at ()
(gdb) info registers
rax 0x7fc15b98450b 140468442121483
rbx 0x19b965e1309e 28284068901022
rcx 0x7fc15b993fa0 140468442185632
rdx 0xfffffffffffec2ff -81153
rsi 0x19b965e1309d 28284068901021
rdi 0x19b965e1309e 28284068901022
rbp 0x7fffc1114500 0x7fffc1114500
rsp 0x7fffc1112500 0x7fffc1112500
r8 0xcccccccccccccccd -3689348814741910323
r9 0x19b95f7cc000 28283961655296
r10 0x1 1
r11 0x19b95f14a70e 28283954833166
r12 0x19b965e1309d 28284068901021
r13 0x19b95f14a70d 28283954833165
r14 0x7fffc11127d0 140736432515024
r15 0x7fffc1112598 140736432514456
rip 0x7fc15b98450b 0x7fc15b98450b <match_at+2603>
eflags 0x213 [ CF AF IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/s 0x19b965e1309e
0x19b965e1309e: "> dnode_it = dnodes_.find(uid.position)\n"
(gdb) x/s 0x19b965e1309d
Will try to get this bug without svn extension and without ccls. Opening this file without a workspace and any extension seems to work fine
Yanpas
commented
4 years ago Well, without steps to reproduce this becomes insane.
The last time I faced this bug was after enabling svn-scm extension ( @JohnstonCode) after 5 minutes of playing with editor trying to catch this bug with ccls extension on.
After several vscode restarts and trying to reproduce the bug in the same fashion (enable svn) I faced freeze for 3-4 seconds and warning in devtools saying smth like 'ExtensionHost: warning using Buffer constructor is deprecated'.
@vballworld can you provide some steps to reproduce?
Im afraid I can't provide anything else...
Yanpas
commented
4 years ago Here is a profile, vsocde didn't freeze, but I felt lags (77 milliseconds of OnigScanner) at the top of the call stack!
Can it help anyhow?
Yanpas
commented
4 years ago @alexr00 Is this bug related to efa12b2f49ec6ee84ed1e7bbd948808efec452f6 ?
alexr00
commented
4 years ago Grammars can cause freezes like this, but if the other extensions are required for the freeze to happen then that is suspicious. Also, grammar related freezes tend to be reproducible 100% of the time.
Yanpas
commented
4 years ago I know what's the problem! ( I added log breakpoint and rule name ).
The output of console:
Line ' std::tuple_element<0, std::pair<pugi::xml_node, std::map<std::basic_string<char>, pugi::xml_node, std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_string<char>, pugi::xml_node> > > > >::type dnode
' ruleid 1 undefined ==,== undefinedThe logpoint:
"Line '", lineText.content, "' ruleid ", rule.id, rule.debugBeginRegExp, " ==,== ", rule.debugEndRegExpI don't have this text in my editor, this text is provided by language server. And it gets matched by grammar for some reason
The first time I catched it:
The text std::tuple_element<1, std::pair<pugi::xml_node, std::basic_string<char>, pugi::xml_node> > > > >::type subnodes↵
The rule name is IncludeOnlyRule#1
Yanpas
commented
4 years ago Yep, this line causes a lot of lags! Just open new editor without any extension and open c++ file. Conclusions:
Line, again:
std::tuple_element<0, std::pair<pugi::xml_node, std::map<std::basic_string<char>, pugi::xml_node, std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_string<char>, pugi::xml_node> > > > >::type dnode
alexr00
commented
4 years ago @Yanpas thank you for the excellent root-causing! I can reproduce the issue with that line.
alexr00
commented
4 years ago Filed in the repo that owns the grammar: https://github.com/jeff-hykin/cpp-textmate-grammar/issues/460
Yanpas
commented
4 years ago And here is the real regex-killer:
std::_Rb_tree_iterator<std::pair<const long, std::pair<pugi::xml_node, std::map<std::basic_string<char>, pugi::xml_node, std::less<std::basic_string<char> >, std::allocator<std::pair<const std::basic_string<char>, pugi::xml_node> > > > > > dnode_it = dnodes_.find(uid.position)And my last two cents: I guess this issue must be in the recovery release ( 1.43.1 ) and I would just roll back grammar to the previous version.
alexr00
commented
4 years ago If we do include it in the recovery release, then yes I'll just roll back the grammar.
alexr00
commented
4 years ago Fix is in the release branch.
aeschli
commented
4 years ago Verified in 1.43.1 fe22a9645b44368865c0ba92e2fb881ff1afce94 2020-03-18T07:01:41.240Z
Steps to Reproduce: Can't upload file. But I'm using vscode with ccls extension editing c++17 source code. After I hit keyboard shortcut "delete current line" several times I often get vscode window to stuck in some infinite loop. The process that is stuck has the following cmdline:
GDB backtrace:
Most probably it's due to the recent update
Does this issue occur when all extensions are disabled?: Yes/No