cpu usage pegged at 100% seemingly forever

[nikomatsakis]

I've had the RLS CPU usage pegged at 100% for hours now. I attached with lldb and found this:

(lldb) thread list
Process 68137 stopped
* thread #1: tid = 0x8035aa8, 0x00007fff8b814362 libsystem_kernel.dylib`read + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  thread #2: tid = 0x8035aa9, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'dispatch-worker'
  thread #3: tid = 0x8035aaa, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10
  thread #4: tid = 0x8035ab7, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-0'
  thread #5: tid = 0x8035ab8, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-1'
  thread #6: tid = 0x8035ab9, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-2'
  thread #7: tid = 0x8035aba, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-3'
  thread #8: tid = 0x8035abb, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-4'
  thread #9: tid = 0x8035abc, 0x00007fff981d413a libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 538, name = 'request-worker-5'
  thread #10: tid = 0x8035abd, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-6'
  thread #11: tid = 0x8035abe, 0x00007fff8b812db6 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'request-worker-7'
  thread #12: tid = 0x8035ac5, 0x00007fff8b813efa libsystem_kernel.dylib`kevent_qos + 10, queue = 'com.apple.libdispatch-manager'

Most of the threads appear to be asleep on cond vars, but here are some backtraces from those that are not:

(lldb) bt
* thread #9: tid = 0x8035abc, 0x00007fff981d413a libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 538, name = 'request-worker-5'
  * frame #0: 0x00007fff981d413a libsystem_platform.dylib`_platform_memmove$VARIANT$Haswell + 538
    frame #1: 0x000000010ac53049 rls`rls::actions::hover::def_docs::h84c8a7c02e311ea2 + 3401
    frame #2: 0x000000010ac5997a rls`rls::actions::hover::tooltip::hb19c98035d91e833 + 15514
    frame #3: 0x000000010ac95832 rls`rls::actions::requests::_$LT$impl$u20$rls..server..dispatch..RequestAction$u20$for$u20$languageserver_types..request..HoverRequest$GT$::handle::heca864bf9951aea0 + 34
    frame #4: 0x000000010ad0cd38 rls`std::panicking::try::do_call::h20e73eac961a07c3 (.llvm.9386041415296837890) + 248
    frame #5: 0x000000010fad964f libstd-574c17a59b6befe6.dylib`__rust_maybe_catch_panic + 31
    frame #6: 0x000000010addd22f rls`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::hd46e553c79eda08c + 127
    frame #7: 0x000000010ad0d31e rls`std::panicking::try::do_call::h492127b77d05a6f5 (.llvm.9386041415296837890) + 46
    frame #8: 0x000000010fad964f libstd-574c17a59b6befe6.dylib`__rust_maybe_catch_panic + 31
    frame #9: 0x000000010adfb244 rls`_$LT$rayon_core..job..HeapJob$LT$BODY$GT$$u20$as$u20$rayon_core..job..Job$GT$::execute::hef56bcace51779e3 (.llvm.10552412072698680047) + 452
    frame #10: 0x000000010b9f4795 rls`rayon_core::registry::WorkerThread::wait_until_cold::h6021efbd2e67db36 + 277
    frame #11: 0x000000010b9f4d79 rls`rayon_core::registry::main_loop::h650605c29f17019e + 649
    frame #12: 0x000000010b9f5850 rls`std::panicking::try::do_call::h2dcd78a9d301588d (.llvm.15849102785470607581) + 48
    frame #13: 0x000000010fad964f libstd-574c17a59b6befe6.dylib`__rust_maybe_catch_panic + 31
    frame #14: 0x000000010b9f5626 rls`_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h49dfef573fc1c964 + 198
    frame #15: 0x000000010facc978 libstd-574c17a59b6befe6.dylib`std::sys_common::thread::start_thread::hce7e523090a00f71 + 136
    frame #16: 0x000000010fa9cb59 libstd-574c17a59b6befe6.dylib`std::sys::unix::thread::Thread::new::thread_start::h461700e9de9353e2 + 9
    frame #17: 0x00007fff9541599d libsystem_pthread.dylib`_pthread_body + 131
    frame #18: 0x00007fff9541591a libsystem_pthread.dylib`_pthread_start + 168
    frame #19: 0x00007fff95413351 libsystem_pthread.dylib`thread_start + 13

and

(lldb) bt
* thread #1: tid = 0x8035aa8, 0x00007fff8b814362 libsystem_kernel.dylib`read + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff8b814362 libsystem_kernel.dylib`read + 10
    frame #1: 0x000000010fab6ef1 libstd-574c17a59b6befe6.dylib`_$LT$std..io..stdio..StdinLock$LT$$u27$a$GT$$u20$as$u20$std..io..BufRead$GT$::fill_buf::h7249bc63fbf626cd + 113
    frame #2: 0x000000010ac40d6e rls`std::io::append_to_string::h79f80e933a63f367 + 62
    frame #3: 0x000000010acfb0a0 rls`_$LT$rls..server..io..StdioMsgReader$u20$as$u20$rls..server..io..MessageReader$GT$::read_message::h8ca8efb05b84c1cc + 176
    frame #4: 0x000000010ac7d894 rls`rls::server::run_server::h2fb6f8dde9ff33a2 + 708
    frame #5: 0x000000010ad95219 rls`rls::main_inner::h9b69d1f4f8f70c58 + 969
    frame #6: 0x000000010ad94e49 rls`rls::main::h43927dbe0d67789f + 9
    frame #7: 0x000000010ad5af06 rls`std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h33dc9d029f2badde + 6
    frame #8: 0x000000010fac7f68 libstd-574c17a59b6befe6.dylib`std::panicking::try::do_call::h1121971afcb56fd2 (.llvm.2181859099862282205) + 24
    frame #9: 0x000000010fad964f libstd-574c17a59b6befe6.dylib`__rust_maybe_catch_panic + 31
    frame #10: 0x000000010faaea1d libstd-574c17a59b6befe6.dylib`std::rt::lang_start_internal::h5737820e17c1b194 + 237
    frame #11: 0x000000010ad956fc rls`main + 44
    frame #12: 0x000000010ac25e34 rls`start + 52

[aloucks]

I'm curious if there's an edge case where the doc extraction is getting into an infinite loop.

Would you be able to build and run using: https://github.com/aloucks/rls/tree/extract-docs-max-line-reads

[alexheretic]

Steps to reproduce would be really useful too, is this bug occurring reliably?

[nikomatsakis]

Pretty reliably, yes. When editing chalk.

[nikomatsakis]

How do I build + run from a custom branch? I've only ever used the RLS from rustup :)

[aloucks]

There are some instructions here: https://github.com/rust-lang-nursery/rls/blob/master/contributing.md

If using vscode, you can set the rust-client.rlsPath to point to your built copy of rls. Note that you'll need to update your path according to the link above. Alternatively you can copy/overwrite the rls executable in the $(rustc --print sysroot)/bin directory.

[bluejekyll]

I'm seeing this very often with trust-dns as well.

[dignifiedquire]

Seeing the same issue on a project of mine, it'll just run for hours. Consuming a full core, without any sign of getting better, until I kill it. (Using it through emacs)

[aloucks]

Can you set RUST_LOG=rls::actions::hover=TRACE and test if this is still an issue after #1091 is merged and the change is reflected in the latest nightly?

[aloucks]

Can you set RUST_LOG=rls::actions::hover=TRACE and test if this is still an issue after #1091 is merged and the change is reflected in the latest nightly?

These changes have been merged. Could you test if this still happening with the latest nightly?