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

[SimonSapin]

$ 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

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::<impl chalk_solve::infer::InferenceTable<I>>::relate ()
#2  0x000055e9b03759cd in chalk_recursive::fulfill::Fulfill<I,Solver>::apply_solution ()
#3  0x000055e9b0379046 in chalk_recursive::fulfill::Fulfill<I,Solver>::solve ()
#4  0x000055e9b04ca543 in chalk_recursive::recursive::Solver<I>::solve_new_subgoal ()
#5  0x000055e9b04c7051 in <chalk_recursive::recursive::Solver<I> as chalk_recursive::solve::SolveDatabase<I>>::solve_goal ()
#6  0x000055e9b04c689b in <chalk_recursive::recursive::RecursiveSolver<I> as chalk_solve::solve::Solver<I>>::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<Q,MP>::read_upgrade ()
#10 0x000055e9b0494b98 in salsa::derived::slot::Slot<Q,MP>::read ()
#11 0x000055e9b03de7df in <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch ()
#12 0x000055e9b03c4956 in <DB as hir_ty::db::HirDatabase>::trait_solve_query::__shim ()
#13 0x000055e9afe70d5e in <DB as hir_ty::db::HirDatabase>::trait_solve_query ()
#14 0x000055e9b03c3490 in hir_ty::db::trait_solve_wait ()
#15 0x000055e9afe70bfe in <DB as hir_ty::db::HirDatabase>::trait_solve ()
#16 0x000055e9b03434ec in hir_ty::infer::InferenceContext::resolve_ty_as_possible::h6527f77c0aced514 ()
#17 0x000055e9b033f242 in hir_ty::infer::pat::<impl hir_ty::infer::InferenceContext>::infer_pat ()
#18 0x000055e9b04c3f59 in <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold ()
#19 0x000055e9b033f423 in hir_ty::infer::pat::<impl hir_ty::infer::InferenceContext>::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<Q,MP>::read_upgrade ()
#23 0x000055e9b048f531 in salsa::derived::slot::Slot<Q,MP>::read ()
#24 0x000055e9b03d6b79 in <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch ()
#25 0x000055e9b03c354f in <DB as hir_ty::db::HirDatabase>::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::<impl core::ops::function::FnMut<A> for &mut F>::call_mut ()
#35 0x000055e9afbbb1c6 in alloc::vec::source_iter_marker::<impl alloc::vec::spec_from_iter::SpecFromIter<T,I> for alloc::vec::Vec<T>>::from_iter ()
#36 0x000055e9afb82c29 in <F as threadpool::FnBox>::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<FnOnce<()>, 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

[DJMcNab]

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

I think automatic updates might have broken around that time.

[flodiebold]

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

[SimonSapin]

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

[SimonSapin]

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

[flodiebold]

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

[SimonSapin]

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.

[Veykril]

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

[flodiebold]

Probably related to being on the OSS version of VSCode?

[SimonSapin]

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?

[flodiebold]

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.

[kekeimiku]

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

[SimonSapin]

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.

[flodiebold]

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

[SimonSapin]

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 #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 :(

[ar37-rs]

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

[SimonSapin]

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.)

[lnicola]

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

[oxalica]

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?

[Veykril]

Closing as this was likely a chalk bug