Server process stuck in an infinite loop(?), eating CPU and not responding to requests

$ rustc --version
rustc 1.52.1 (9bc8c42bb 2021-05-09)
$ ~/.config/Code\ -\ OSS/User/globalStorage/matklad.rust-analyzer/rust-analyzer-x86_64-unknown-linux-gnu --version
rust-analyzer 2021-04-12-92-g7570212a5

2021-04-12 seems kinda old but I don’t know how to update it. VSCode says the extension is up to date.

I don’t know what situations trigger this, but while working on Mercurial I semi-often have a rust-analyzer process (started by VSCode) start using ~100% of one CPU thread and stop responding to any query. In particular, saving a file does nothing at first while the editor waits for the formatter to respond. Only after three seconds does a "Waiting" dialog appear with a "Cancel" button, which allows saving without formatting. The only viable way to continue working is to disable the rust-analyzer extension entirely.

Disabling the extension or exiting the editor leaves that process running and eating CPU until I kill it manually.

perf top -p shows almost all of the time is spent in __memmove_avx_unaligned_erms. Starting gdb -p to stop the process at a random time and using thread apply all where shows many threads waiting and one with the following call stack:

Stack

```rust Thread 27 (LWP 595217 "rust-analyzer-x"): #0 0x00007f288cd83897 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6 #1 0x000055e9b042e375 in chalk_solve::infer::unify::>::relate () #2 0x000055e9b03759cd in chalk_recursive::fulfill::Fulfill::apply_solution () #3 0x000055e9b0379046 in chalk_recursive::fulfill::Fulfill::solve () #4 0x000055e9b04ca543 in chalk_recursive::recursive::Solver::solve_new_subgoal () #5 0x000055e9b04c7051 in as chalk_recursive::solve::SolveDatabase>::solve_goal () #6 0x000055e9b04c689b in as chalk_solve::solve::Solver>::solve_limited () #7 0x000055e9b02de809 in hir_ty::traits::trait_solve_query () #8 0x000055e9b04fa430 in salsa::runtime::Runtime::execute_query_implementation () #9 0x000055e9b046f6db in salsa::derived::slot::Slot::read_upgrade () #10 0x000055e9b0494b98 in salsa::derived::slot::Slot::read () #11 0x000055e9b03de7df in as salsa::plumbing::QueryStorageOps>::try_fetch () #12 0x000055e9b03c4956 in ::trait_solve_query::__shim () #13 0x000055e9afe70d5e in ::trait_solve_query () #14 0x000055e9b03c3490 in hir_ty::db::trait_solve_wait () #15 0x000055e9afe70bfe in ::trait_solve () #16 0x000055e9b03434ec in hir_ty::infer::InferenceContext::resolve_ty_as_possible::h6527f77c0aced514 () #17 0x000055e9b033f242 in hir_ty::infer::pat::::infer_pat () #18 0x000055e9b04c3f59 in as core::iter::traits::iterator::Iterator>::fold () #19 0x000055e9b033f423 in hir_ty::infer::pat::::infer_pat () #20 0x000055e9b0341ce6 in hir_ty::infer::infer_query () #21 0x000055e9b04fa960 in salsa::runtime::Runtime::execute_query_implementation () #22 0x000055e9b045522f in salsa::derived::slot::Slot::read_upgrade () #23 0x000055e9b048f531 in salsa::derived::slot::Slot::read () #24 0x000055e9b03d6b79 in as salsa::plumbing::QueryStorageOps>::try_fetch () #25 0x000055e9b03c354f in ::infer_query::__shim () #26 0x000055e9b03c3378 in hir_ty::db::infer_wait () #27 0x000055e9b0443583 in hir_ty::diagnostics::validate_body () #28 0x000055e9b029310e in hir::Function::diagnostics () #29 0x000055e9b0290225 in hir::Module::diagnostics () #30 0x000055e9afeb1ed6 in ide::diagnostics::diagnostics () #31 0x000055e9afecc33b in std::panicking::try () #32 0x000055e9afebac36 in ide::Analysis::diagnostics () #33 0x000055e9afcad729 in rust_analyzer::handlers::publish_diagnostics () #34 0x000055e9afb545a0 in core::ops::function::impls:: for &mut F>::call_mut () #35 0x000055e9afbbb1c6 in alloc::vec::source_iter_marker:: for alloc::vec::Vec>::from_iter () #36 0x000055e9afb82c29 in ::call_box () #37 0x000055e9afcb50db in std::sys_common::backtrace::__rust_begin_short_backtrace::h75d3346417357e7a () #38 0x000055e9afcb6ee6 in core::ops::function::FnOnce::call_once{{vtable-shim}} () #39 0x000055e9b08eff9a in alloc::boxed::{{impl}}::call_once<(),FnOnce<()>,alloc::alloc::Global> () at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/alloc/src/boxed.rs:1521 #40 alloc::boxed::{{impl}}::call_once<(),alloc::boxed::Box, alloc::alloc::Global>,alloc::alloc::Global> () at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/alloc/src/boxed.rs:1521 #41 std::sys::unix::thread::{{impl}}::new::thread_start () at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0//library/std/src/sys/unix/thread.rs:71 #42 0x00007f288cf3a299 in start_thread () from /usr/lib/libpthread.so.0 #43 0x00007f288cd1e053 in clone () from /usr/lib/libc.so.6 ```

Have you tried uninstalling and reinstalling the code extension? Maybe disabling nightly too

I think automatic updates might have broken around that time.

It's unlikely to help with the infinite loop though; that might be the same as #7680 or #7796.

Is 2021-04-12-92-g7570212a5 a Nightly version? I have "rust-analyzer.updates.channel": "stable" in settings, though

Removing the ~/.config/Code\ -\ OSS/User/globalStorage/matklad.rust-analyzer/ directory and reinstalling the extension downloads the same version again.

It's probably stable; there was a bug with the version number generation. What version of the rust-analyzer plugin do you have installed?

The just-reinstalled VSCode extension is v0.2.563. I believe it was previously the same, since it said "no update available" when I made it check.

This week's stable release version is 0.2.591, so your version is one month old it seems

Probably related to being on the OSS version of VSCode?

Indeed, I’m using the Archlinux package which doesn’t have "Microsoft specific customizations" that upstream builds have. Is any of these customizations known to affect the rust-analyzer extension?

How does the extension decide which version of the server executable to download? Is there config to influence that, beyond the stable v.s. nightly switch?

I don't use VSCode, but IIRC, the OSS version doesn't have the official Marketplace, but a different one. We don't publish to that other marketplace, but I think they mirror the extension; there might be a delay though.

The extension version directly controls the downloaded stable version, so if you're on a month-old extension, you get a month-old server version as well.

I also have this problem, I manually download and install from here https://marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer

Oh indeed! TIL that the Archlinux package is configured to use https://open-vsx.org/ instead of Microsoft’s Marketplace. This explains a lot. It’s also in the documented differences. I’ll try to get the version there updated, or failing that install the .vsix manually.

@kekeimiku if you mean the endless loop, as mentioned that's probably one of the linked issues above.

With the v0.2.591 extension and rust-analyzer fd109fb58 2021-05-10 stable server I still see the same symptoms. This may be another case of https://github.com/rust-analyzer/rust-analyzer/issues/7796.

Unfortunately this makes rust-analyzer unusable for me, since this hang happens fairly quickly every time I restart the IDE with the extension enabled on this project :(

windows 10 rust gnu user, same problem here. temporary switch back to RLS.

For now I’ve downgraded to v0.2.538 (from the .vsix file) and disabled automatic extension updates, and haven’t reproduced this bug since. (This isn’t a precise bisection, just a guess based on dates in https://github.com/rust-analyzer/rust-analyzer/releases and when I remember starting to see this bug.)

FWIW, I can't reproduce this with analysis-stats (or even analysis-stats --with-deps).

I ran into this quite frequently on rust-analyzer 2021-11-29, with the same call stack.

Is it possible to make a hard time limit for chulk as workaround?

Closing as this was likely a chalk bug

rust-lang / rust-analyzer

Server process stuck in an infinite loop(?), eating CPU and not responding to requests #8792