erlang ls with vscode stops working, uses 100% CPU when vscode is closed

[hackerjones]

Describe the bug
While using erlang ls with vscode all functions stop working. Exiting vscode or doing a window reload will restore functionality.
If I exit vscode and look at top (htop) I can see erlang_ls using ~100% CPU. I have to use kill to terminate these processes.

The following line is seen in the server log when this happens:

[2022-01-19T13:30:13.152297-06:00] [info] noop_group_leader got [message={get,#Ref<0.967863121.2412249089.236661>,<0.139.0>}] [els_sup:noop_group_leader/0 L115] <0.135.0>

To Reproduce
Use erlang_ls with vscode

Expected behavior
Not to stop functioning and using ~100% CPU

Actual behavior
All functions stop working and when exiting vscode erlang_ls processes are still running using ~100% CPU

Context

• erlang_ls version (tag/sha):
  
• Editor used: vscode
• LSP client used: vscode

[robertoaloi]

Thanks for reporting @hackerjones . Is the issue consistently or occasionally happening? Could you share your erlang_ls.config? We received similar reports which seemed related to Dialyzer/Typer (via the suggest-spec lens).

[hackerjones]

I have tried disabling and enabling different diagnostics such as dialyzer and crossref as well as various lenses without any improvement. It is quite consistent I cannot work more than 5 minutes without this happening.

erlang_ls.config.txt

[hackerjones]

I have also noted that when exiting vscode while having the erlang_ls extension enabled. erlang_ls sometimes never appears to stop executing. If I reopen vscode I then get the following issue:

https://stackoverflow.com/questions/67698176/error-loading-webview-error-could-not-register-service-workers-typeerror-fai

[mcesaro]

This seems related or the same issue as #1155 ?

[keynslug]

For me this is happening occasionally, yet I was able to trace one of those occasions and reconstruct the following scenario.

1. The els_server process receives "resolve" request which is eventually dispatched to els_methods:completionitem_resolve/2.

2. The els_completion_provider then attempts to handle it, calling els_docs:function_docs/4 function, which then calls edoc/3 function in the same module.

3. This function installs temporary group leader for the executing process.

4. Then, inside the try clause docsh_docs_v1:lookup/3 is being called. Notice that at this point the result of the call isn't being matched against any pattern.

5. Right after that temporary group leader is told to shut down. That effectively restores original group leader for the process.

6. The result of the call (4) is matched against an {ok, _} pattern, yet docsh explicitly tells that erroneous results are possible. In my case that causes this expression to fail with badmatch exception.

7. Exception handler tries to shut down temporary group leader second time. At this time the process already has original "noop" group leader, which does not handle {get, Ref, self()} messages, therefore does not respond to them.

This sequence of events causes els_completion_provider and subsequently els_server processes to become stuck and unable to handle any requests.

I guess that adding a codepath to handle not_found result from docsh should be enough to close the issue. Yet, generally speaking, I believe such patterns (async communication with no controlled timeouts in the core event loop) should ideally be avoided.

---

For the sake of completeness:

• Erlang LS: 0.21.2

• Erlang/OTP: 24.2

• VSCode: 1.64.2

• Backtrace of the els_completion_provider process (notice the badmatch tuple in the stack).

  Program counter: 0x00007fb3a23f3868 (els_docs:flush_group_leader_proxy/1 + 440)
  y(0)     []
  y(1)     []
  y(2)     #Ref<0.3174242374.62652417.86872>
  
  0x00007fb31250a028 Return addr 0x00007fb3a23f30a0 (els_docs:edoc/3 + 1080)
  y(0)     {4965568931671630943272532559218897914456307912134819652127799561444762267378221339660877868925480448673224679979419626461877648815826190041027082834697364155270119991840634782171973651668773998569165197738516681808,true,[]}
  y(1)     {badmatch,{not_found,<<73,116,101,109,32,100,101,115,99,114,105,112,116,105,111,110,32,105,115,32,110,111,116,32,97,118,97,105,108,97,98,108,101,46,10>>}}
  y(2)     []
  y(3)     error
  y(4)     1
  y(5)     f
  y(6)     hg_invoice
  y(7)     []
  
  0x00007fb31250a070 Return addr 0x00007fb3a23f0da4 (els_docs:function_docs/4 + 492)
  y(0)     [{code_block_begin,"erlang"},{code_block_line,"f(PaymentSession) "},{code_block_end,"erlang"}]
  y(1)     []
  y(2)     []
  y(3)     []
  y(4)     {h2,[...]}
  

• Stacktrace of the els_completion_provider.

  [{els_docs,flush_group_leader_proxy,1,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_lsp/src/els_docs.erl"},
        {line,394}]},
   {els_docs,edoc,3,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_lsp/src/els_docs.erl"},
        {line,349}]},
   {els_docs,function_docs,4,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_lsp/src/els_docs.erl"},
        {line,101}]},
   {els_completion_provider,resolve,1,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_lsp/src/els_completion_provider.erl"},
        {line,86}]},
   {els_completion_provider,handle_request,2,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_lsp/src/els_completion_provider.erl"},
        {line,74}]},
   {els_provider,handle_call,3,
       [{file, "/tmp/repository/main/erlang_ls/apps/els_core/src/els_provider.erl"},
        {line,93}]},
   {gen_server,try_handle_call,4,
       [{file,"gen_server.erl"},{line,721}]},
   {gen_server,handle_msg,6,
       [{file,"gen_server.erl"},{line,750}]}]
  

[keynslug]

Proposed a fix in #1198.