SIGSEGV crash: LMDB reader slot leak causes MDB_READERS_FULL after multiple nvim sessions

[imroc]

Summary

fff.nvim's Rust extension segfaults with SIGSEGV when opening the file picker, caused by LMDB reader slot exhaustion (MDB_READERS_FULL).

Crash Banner

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 ===

Root Cause

fff.nvim leaks LMDB reader slots. Each Neovim session that loads fff.nvim occupies ~12-18 reader slots in the LMDB lock file (lock.mdb) but never releases them. The default maxreaders limit is 126, so after ~7-10 long-running nvim sessions, the reader table is exhausted.

When a new nvim session tries to open fff's file picker, LMDB returns MDB_READERS_FULL, which is not handled gracefully and leads to a segfault.

Log Evidence

From the fff log file (~/.local/state/nvim/fff+*.log):

2026-07-09T04:06:34.742389Z ERROR ThreadId(02) fff_nvim::error: string_value="Failed to start read transaction for frecency database: MDB_READERS_FULL: Environment maxreaders limit reached"

=== 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 ===

Reader Slot Analysis

Parsing the LMDB lock file (~/.cache/nvim/fff_nvim/lock.mdb) shows all 126 reader slots occupied:

Max readers: 126
Used slots: 126 (alive=115, dead=11)
Free slots: 0

7 long-running nvim processes (running for 1-3 days) each leaked 12-18 reader slots:

PID	Slots Leaked	Process Age
1911588	16	~1 day
2171829	17	~1 day
2326348	17	~1 day
2411364	17	~1 day
573667	12	~3 days
3123117	17	~2 hours
2459610	18	~1 day
3219827	6 (dead)	crashed
Total	126/126

Note: clear_stale_readers() is called at env open, but it only reclaims slots from dead processes. Slots held by alive nvim processes are never released, even though each process should only need 1-2 reader slots at a time.

Reproduction

1. Open multiple nvim sessions over time (7+ sessions running for 1+ days each)
2. In a new nvim session, trigger the fff file picker (e.g., <leader><space> or ff)
3. fff.nvim crashes with SIGSEGV, nvim exits

Environment

• OS: Linux x86_64 (devcontainer, AMD EPYC 7K62)
• Neovim version: built from source (LazyVim distribution)
• fff.nvim version: 0.9.7-nightly.1a8ef35 (commit 1a8ef35)
• Binary: prebuilt x86_64-unknown-linux-gnu.so downloaded from GitHub releases
• Rustc (for local build fallback): 1.96.1

Workaround

Delete the LMDB lock file to reset the reader table:

rm -f ~/.cache/nvim/fff_nvim/lock.mdb
rm -f ~/.local/share/nvim/fff_queries/lock.mdb

This preserves the frecency data in data.mdb but resets all reader slots. LMDB recreates the lock file on next open.

Suggested Fix

The reader slot leak appears to be in the LMDB transaction handling — read transactions are opened but not properly closed/committed in some code paths, leaving reader slots occupied indefinitely. The clear_stale_readers() call at env open only helps with dead processes, not alive ones that have leaked slots.

Potential areas to investigate:

• open_database_safe() in crates/fff-core/src/dbs/lmdb.rs — read transactions are committed, but if any code path opens additional read transactions without proper cleanup, slots leak
• Background watcher / scan threads that may open read transactions
• The SharedDb<T> refactor (commit 18f546b) that replaced two LMDB handles — may have introduced the leak

[dmtrKovalenko]

@gustav-fff this is not triaged wtf

we fixed this, check if the latest commit refactor is the culprit of this?

[gustav-fff]

[triage-bot] REPRODUCED:
Reproduced on origin/main. Branch: triage-bot/issue-664.

Root cause: EnvOpenOptions::new() defaults to WithTls (see crates/fff-core/src/dbs/lmdb.rs:155), which sets LMDB in the TLS mode where reader locktable slots are tied to OS threads, not to MDB_txn objects. heed 0.22 docs: "When used to open transactions: A thread can only use one transaction at a time... Each transaction belongs to one thread." fff opens read txns from many threads (BACKGROUND_THREAD_POOL rayon workers, background_watcher, fff-lmdb-gc, git_status_worker, and the neovim main thread). Every thread that ever opens a read txn permanently occupies a reader slot for the lifetime of the process, even after the txn commits. With maxreaders = 126 (default), a handful of long-running nvim sessions exhaust the reader table and new nvim processes hit MDB_READERS_FULL. On the segfault path: Error::DbStartReadTxn from open_database_safe() is returned during init, then Lua-side error handling races the destructor and derefs into an already-unmapped LMDB region.

Steps to reproduce (script):

// tests/lmdb_reader_slot_leak.rs
use fff_search::frecency::FrecencyTracker;
let dir = tempfile::tempdir().unwrap();
let t = FrecencyTracker::open(dir.path()).unwrap();
for _ in 0..200 {
    std::thread::spawn({
        let t_env = t.env().clone();
        move || { let r = t_env.read_txn().unwrap(); r.commit().unwrap(); }
    }).join().unwrap();
}
// env.info().num_readers ≈ 200, not ~0 — every thread leaked a slot

Actual: reader count keeps climbing 1:1 with thread count; hits MDB_READERS_FULL at 127.
Expected: reader count returns to near-zero after each commit().

Working on fix on triage-bot/issue-664.

Honk-Honk 🪿

[gustav-fff]

[triage-bot] DIRECTED:
Not the SharedDb<T> refactor (#617) — that only moved code around, didn't touch env open flags. Culprit is much older: EnvOpenOptions::new() has always been used at crates/fff-core/src/dbs/lmdb.rs:155, and heed 0.22's default is WithTls, which pins reader slots to OS threads. Every thread that ever runs read_txn() — rayon workers, background_watcher, fff-lmdb-gc, git_status_worker, main — burns a slot for the process lifetime.

Fix pushed as #665: open with read_txn_without_tls() and thread Env<WithoutTls> through LmdbStore / FrecencyTracker / QueryTracker / DbHealthChecker. Regression test at crates/fff-core/tests/lmdb_reader_slot_leak.rs spawns 400 short-lived reader threads; pre-fix fails around thread 127 with MDB_READERS_FULL, post-fix all 400 succeed. cargo test -p fff-search --lib clean (98 pass).

Honk-Honk 🪿

[imroc]

Still not resolved

[dmtrKovalenko]

Yeah I didn't merge the PR cause I doubt it will help. Will you be able to test it out on the Gustavs branch?