Solargraph: High CPU load after initialize

[arashm]

I'm using solargraph with VIM + coc.nvim plugin. A few minutes after solargraph is initialized, it shortly becomes a zombie process and doesn't respond. For the first few minutes it just works fine.

More info:
OS: MacOS
VIM Version: 8.2.250
coc.nvim version: master
solargraph version: 0.38.5
ruby version: 2.6.3

Here's some logs I collected using rbspy for 35 seconds when the process gone zombie:

Summary of profiling data so far:
% self  % total  name
 49.91   100.00  <c function> - unknown
 13.42    36.44  fqns_pins - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/store.rb
  7.38    21.60  get_qualified_namespace - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/cache.rb
  7.24    46.80  namespace_exists? - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/store.rb
  4.15    99.51  super_and_sub? - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  4.06    38.22  qualify - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  4.00    53.00  get_superclass - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/store.rb
  3.55     3.60  fqns_pins_map - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/store.rb
  3.06     3.12  block in cache - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  1.66     3.18  block in store - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  0.63     1.46  superclass_references - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map/store.rb
  0.51     3.40  cache - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  0.43     2.80  store - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/api_map.rb
  0.00    99.51  update - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/backport-1.1.1/lib/backport/server/tcpip.rb
  0.00    99.51  tick - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/backport-1.1.1/lib/backport/client.rb
  0.00    99.51  receiving - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/language_server/transport/adapter.rb
  0.00    99.51  receive - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/language_server/transport/data_reader.rb
  0.00    99.51  receive - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/language_server/host.rb
  0.00    99.51  read_input - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/backport-1.1.1/lib/backport/client.rb
  0.00    99.51  process - /Users/amousavi/.rbenv/versions/2.6.3/lib/ruby/gems/2.6.0/gems/solargraph-0.38.5/lib/solargraph/language_server/transport/adapter.rb

rbspy-2020-02-25-zqcXJsAAxp.raw.gz

[castwide]

I suspect this has something to do with resolving class inheritance. Is there any chance you can give me a reproducible example of a file that causes the problem?

One thing you can try that might help: run solargraph scan -v from your project root. If there's something in the inheritance tree that causes an infinite loop, the scan might freeze at the same location. More information: https://solargraph.org/guides/scanning-workspaces

[arashm]

The scan worked fine with no error or a loop. I think I found the issue though. I had another plugin, ALE, that used solargraph as linter. So ALE and coc.nvim were each running their own solargraph on the same workspace and that seems to have caused some issues. I removed solargraph from the linter and seems to just work fine.

I close this for now, since the process hasn't gone zombie even after a couple of hours.

[arashm]

Nope. It went zombie again after a while :(

[castwide]

Is there an error log you can check? My experience with vim is limited, so I'm not even sure where to look for one.

[arashm]

I can't see any errors on VIM side. After solargraph goes unresponsive, coc.nvim plugin starts throwing timeout errors when calling solargraph.

I realized that, as soon as I start adding codes to code base, and when they have reference to self, solargraph's cpu usage spikes. I tried to run the solargraph scan -v while the added code is there, but it finished just fine.

see the video: 
Screen Recording 2020-03-03 at 13.39.57.zip

I'm not sure how to get more logs from solargraph.

[castwide]

Thanks for catching that. I don't know what the root cause is, but I'll look into it.

[Jacobkg]

I also have been having issues where the ruby process inside VSCode starts spinning at 99% CPU and making my fan go crazy.

[praveendhawan]

I am also facing this issue and have to restart the solargraph server after every 1-2 hours.

[lgsanjos]

same here, I have the impression that it only started happening after updating to my OSX to Catalina 10.15.3 but might be just a coincidence.

[castwide]

The master branch has an update that fixes a name collision problem in class inheritance (#290). That's likely to be the most common cause of server freezes. There's also a fix for a less frequent problem involving recursive variable references (#293). Both fixes will be released in v0.38.6 in the next day or so.

[castwide]

Released in v0.38.6.

[praveendhawan]

@castwide updated gem to v0.38.6 and since then, haven't faced any timeouts. Also don't feel the need to restart server every now and then. Thanks

[arashm]

I haven't notice any issue after v0.38.6 as well. Thanks @castwide. Should have been hard to debug and fix. Your doing an awesome job!