Segfault instead of a clean error when base_path is the filesystem root (/)

[jabdinghoff]

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

2026-08-05T10:33:59.966249Z  INFO ThreadId(02) fff_search::log: FFF tracing initialized: /home/jabdinghoff/.local/state/nvim/fff+1785926039+7921.log (pid=7921, retain_runs=20)
2026-08-05T10:33:59.966316Z  INFO ThreadId(02) open_env{db_path="/home/jabdinghoff/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: new
2026-08-05T10:33:59.966396Z  INFO ThreadId(02) open_env{db_path="/home/jabdinghoff/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: close time.busy=72.3µs time.idle=8.71µs
2026-08-05T10:33:59.967644Z  INFO ThreadId(02) fff_nvim: Frecency database initialized at /home/jabdinghoff/.cache/nvim/fff_nvim
2026-08-05T10:33:59.967733Z  INFO ThreadId(02) open_env{db_path="/home/jabdinghoff/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: new
2026-08-05T10:33:59.968053Z  INFO ThreadId(02) open_env{db_path="/home/jabdinghoff/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: close time.busy=214µs time.idle=106µs
2026-08-05T10:33:59.968109Z  INFO ThreadId(02) fff_nvim: Query tracker database initialized at /home/jabdinghoff/.local/share/nvim/fff_queries
2026-08-05T10:33:59.968121Z ERROR ThreadId(02) fff_search::file_picker: Refusing to index filesystem root: /
2026-08-05T10:33:59.968124Z ERROR ThreadId(02) fff_nvim::error: string_value="Can not run certain FFF features in a file system root or home directories. Consider smaller per-project directories."

=== CRASH SIGSEGV (fff) ===
fff.nvim's rust extension hit a segfault and is about to die.
Please file the bug at https://github.com/dmtrKovalenko/fff/issues with this banner attached.
=== CRASH END SIGSEGV ===

Description

When I open nvim at / I get a buffer with:

~     === CRASH SIGSEGV (fff) ===
~                                fff.nvim's rust extension hit a segfault and is about to die.
~                                                                                             Please file the bug at https://github.com/dmtrKovalenko/fff/issues with this banner attached.
~                                             === CRASH END SIGSEGV ===
~

before it then fully crashes.

This is on aarch64 on wsl2 on Ubuntu 24.04

[dmtrKovalenko]

But it is not segfaulting (god I should remove the subscriber) - as you can see in a lint above fff by default refusing to start in a system root and returns an error.

You can change the behavior in settings there is enable_fs_root_scanning)

[jabdinghoff]

I don't really understand? it crashes my entire nvim process and that is intended? I think not starting fff here is reasonable and I do not want it to, but I still want to be able to use nvim ^^

[dmtrKovalenko]

Do you use lazy=false?

[dmtrKovalenko]

@gustav-fff check if we can intercept this exception at the lua level and prevent neovim crashing

[jabdinghoff]

Do you use lazy=false?

yes!

[dmtrKovalenko]

This would be a workaround to fix it for now and I'll make sure it doesn't crash the neovim

[jabdinghoff]

I compiled fff-nvim with zlob on my machine and now it doesn't crash nvim; no more segfault. the ci cross-compiles to aarch64. maybe it has something to do with that?

[dmtrKovalenko]

wait there is technically no crash and no segfault fff just exits with an error

[jabdinghoff]

maybe i am misunderstanding something...

on the published fff v0.10.1 aarch64-unknown-linux-gnu.so:

$ cd / && nvim --headless -c "lua require('fff.core').ensure_initialized()" -c "qa!"; echo "exit=$?"

=== CRASH SIGSEGV (fff) ===
=== CRASH END SIGSEGV ===
Segmentation fault (core dumped)
exit=139

139 = 128 + 11 (SIGSEGV), and it dumps core. Under gdb:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/cj4jysawj8cc6yv2cwdgzxhdhq7dnf05-glibc-2.42-67/lib/libthread_db.so.1".
[New Thread 0xffffe99ff160 (LWP 10571)]
[New Thread 0xffffe88cd160 (LWP 10572)]
[New Thread 0xffffe83bb160 (LWP 10573)]
[Thread 0xffffe83bb160 (LWP 10573) exited]
[Thread 0xffffe88cd160 (LWP 10572) exited]

Thread 1 "nvim" received signal SIGSEGV, Segmentation fault.
0x0000ffffffffbda0 in ?? ()
#0  0x0000ffffffffbda0 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
pc             0xffffffffbda0      0xffffffffbda0
lr             0xffffe9490cb4      281474595622068
x0             0xffffffffb538      281474976691512
From                To                  Syms Read   Shared Object Library
0x0000ffffe8bd0000  0x0000ffffe9510000  Yes (*)     /home/jabdinghoff/.local/share/nvim/lazy/fff.nvim/target/release/libfff_nvim.so
(*): Shared library is missing debugging information.

Only the published CI binaries do this. cargo build --release -p fff-nvim from the same
commit exits 0 with the clean error, with or without --features zlob. Tested on aarch64
WSL2 (glibc 2.39, nvim 0.12.4).

[gustav-fff]

[triage-bot] DIRECTED: Yes, catchable at Lua level. PR #748.

The pcall around init_file_picker (lua/fff/core.lua) cannot catch this — it is a SIGSEGV, a hardware signal, not a Lua/FFI error. Rust is supposed to return Error::FilesystemRoot cleanly (crates/fff-core/src/file_picker.rs:862) and a native cargo build --release does; the published aarch64 .so segfaults at the FFI call instead (matches @jabdinghoff: exit=139, core dump, native build exits 0).

Workaround: mirror the root/home refusal in Lua and bail before crossing into Rust, so the crashing path is never reached. Guard added to ensure_initialized and change_indexing_directory. Honors enable_fs_root_scanning / enable_home_dir_scanning. ~40 LOC.

The underlying aarch64 codegen/segfault is separate and still yours to chase — this only stops it from taking neovim down.

Honk-Honk 🪿

[gustav-fff]

[triage-bot] DIRECTED: yes, it can be intercepted at the lua level.

Not a segfault. The SIGSEGV banner is the signal handler installed unconditionally at module load (crates/fff-core/src/log.rs:71 via crates/fff-nvim/src/lib.rs:1029), so it prints for whatever kills nvim afterwards, not for the rust guard. The guard itself returns clean: crates/fff-core/src/file_picker.rs:862 -> Error::FilesystemRoot -> crates/fff-nvim/src/error.rs.

Repro on pre-fix main, cwd /, lazy_sync = false:

Failed to initialize file picker: runtime error: Can not run certain FFF features in a file system root or home directories. Consider smaller per-project directories.
stack traceback:
	...fff/lua/fff/core.lua:150: in field 'ensure_initialized'

lua/fff/core.lua:150 already pcalls it, so on macOS nvim survives. Reporter is aarch64/WSL2 and I could not reproduce the process death there — the banner means the fatal part happens after the guard returns, i.e. in the teardown behind it, which the pcall does not cover.

Workaround, mirroring the rust guard in lua so the FFI call never happens:

-- lua/fff/core.lua
if not config.enable_fs_root_scanning and vim.fs.dirname(abs) == abs then ... end

Applied at both entry points (ensure_initialized, change_indexing_directory). ensure_initialized still arms the autocmds when refusing, so a later :cd into a real project recovers instead of the picker staying dead for the session:

after_init  cwd=/  picker_init=false
after_cd    base_path=/Users/.../fff  indexed=350

Verified: new tests/fs_root_refusal_spec.lua — 4 pass with the patch, 2 fail without it. cargo clippy and stylua --check clean. Full make test-lua did not finish here: target/ kept getting deleted mid-build by something outside the repo, unrelated to this change.

This only stops fff from handing / to the indexer. It does not fix whatever actually kills nvim on WSL2 aarch64 after the guard fires — @dmtrKovalenko you said you'd take that part.

Say the word and I open the PR.

Honk-Honk 🪿

[dmtrKovalenko]

I don't think this is right why does cross compiled binaries throw a segfault in case of root scanning @gustav-fff