Hang on "roots scanned" on projects with flatpak-builder folders due to FS walk over a symlink

[YaLTeR]

Somewhere over the last few updates, rust-analyzer started hanging on "roots scanned" on some of my projects, notably gtk-rs applications. I dumped its stack and found out it's recursively walking build folders from Flatpak which contains a symlink to /run which contains, among other things, all files ever opened in Flatpak apps via the xdg-document-portal. Here's an example rust-analyzer backtrace during the issue:

Thread 2 (Thread 0x7fecd95f7640 (LWP 35524) "rust-analyzer-x"):
#0  __GI___open64_nocancel (file=0x7fec9d4d7bd0 "/home/yalter/source/rs/video-trimmer/build-dir-devel/var/run/user/1000/doc/by-app/org.gnome.PortalTest/a71dcf2e/home/yalter/oops, a completely unrelated path from wherever in the filesystem"..., oflag=591872) at ../sysdeps/unix/sysv/linux/open64_nocancel.c:45
#1  0x00007fecd9ac8649 in __opendir (name=<optimized out>) at ../sysdeps/posix/opendir.c:92
#2  0x000055e15dbe8ce6 in std::sys::unix::fs::readdir () at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/sys/unix/fs.rs:1003
#3  0x000055e15d0bf74a in walkdir::IntoIter::push ()
#4  0x000055e15d0bf11c in walkdir::IntoIter::handle_entry ()
#5  0x000055e15d0be73c in <walkdir::IntoIter as core::iter::traits::iterator::Iterator>::next ()
#6  0x000055e15d08d3c2 in <walkdir::FilterEntry<walkdir::IntoIter,P> as core::iter::traits::iterator::Iterator>::next ()
#7  0x000055e15d093cbb in <alloc::vec::Vec<T,A> as alloc::vec::SpecExtend<T,I>>::spec_extend ()
#8  0x000055e15d08c474 in vfs_notify::NotifyActor::run ()
#9  0x000055e15d08e103 in std::sys_common::backtrace::__rust_begin_short_backtrace ()
#10 0x000055e15d08e573 in core::ops::function::FnOnce::call_once{{vtable-shim}} ()
#11 0x000055e15dbedb8a in alloc::boxed::{{impl}}::call_once<(),FnOnce<()>,alloc::alloc::Global> () at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/alloc/src/boxed.rs:1328
#12 alloc::boxed::{{impl}}::call_once<(),alloc::boxed::Box<FnOnce<()>, alloc::alloc::Global>,alloc::alloc::Global> () at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b/library/alloc/src/boxed.rs:1328
#13 std::sys::unix::thread::{{impl}}::new::thread_start () at /rustc/cb75ad5db02783e8b0222fee363c5f63f7e2cf5b//library/std/src/sys/unix/thread.rs:71
#14 0x00007fecd9d193f9 in start_thread (arg=0x7fecd95f7640) at pthread_create.c:463
#15 0x00007fecd9b00b53 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

rust-analyzer in VSCode version v0.2.529, Fedora 33

[bilelmoussaoui]

I think it would be wise to ignore folders in .gitignore which will likely solve the issue here

[onkoe]

I'm using the relm4-template for my project. However, I starting having my computer completely freeze randomly. After a few hours of troubleshooting the rest of my janky-aaa setup, I saw that rust-analyzer was eating GB of memory just a few seconds after VSCode started my project. It then continued to take up all memory it could until the lights went out.

Anyways, for the relm4-template or gtk-rust-template, you can use this in your project's local .vscode/settings.json to make your computer stay on:

{
    "rust-analyzer.check.command": "clippy",
    "rust-analyzer.files.excludeDirs": [
        ".flatpak-builder",
        "build-aux",
        "build",
        "flatpak_app"
    ]
}

The clippy check command has nothing to do with it. But it's useful! Give it a try too :)

[adhadse]

@onkoe What if we are using any other Text editor other than VSCode? Any ideas?

[onkoe]

@adhadse It should be as simple as configuring these options of r-a for your editor! I'd really like to get an editor-independent configuration file as discussed on the forums.

It's also mentioned in #13529