[fff.nvim] fff causing segmentation fault (SIGSEGV)

[jemabaris]

Today I suddenly had neovim crashing on me upon every start ( neovim never crashed on me before) which I was very surprised about. I ran a backtrace and it turns out that fff is causing segfaults. I am not sure but I think it's being triggered when opening neovim via kitty-scrollback.nvim and once this causes the segfault every attempt to launch neovim normally also results in SIGSEGV. This is the backtrace:

backtrace.txt

Would be much appreciated if you could have a look into this soon as it seams to be a serious issue.

All the best

Janis

[dmtrKovalenko]

which version did you use?

[dmtrKovalenko]

can you also please attach fff.log by running :FFFLog

[jemabaris]

There is no :FFFLog command, I guess you meant :FFFOpenLog?

2026-05-20T16:41:00.208296Z  INFO fff_search::log: FFF tracing initialized with log file: /home/janis/.local/state/nvim/fff.log
2026-05-20T16:41:00.208334Z  INFO open_env{db_path="/home/janis/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: new
2026-05-20T16:41:00.208421Z  WARN open_env{db_path="/home/janis/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: reclaimed stale LMDB reader slots at open cleared=30
2026-05-20T16:41:00.208427Z  INFO open_env{db_path="/home/janis/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: close time.busy=89.4µs time.idle=4.28µs
2026-05-20T16:41:00.208461Z  INFO fff_nvim: Frecency database initialized at /home/janis/.cache/nvim/fff_nvim
2026-05-20T16:41:00.208467Z  INFO open_env{db_path="/home/janis/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: new
2026-05-20T16:41:00.208519Z  WARN open_env{db_path="/home/janis/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: reclaimed stale LMDB reader slots at open cleared=2
2026-05-20T16:41:00.208522Z  INFO open_env{db_path="/home/janis/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: close time.busy=54.5µs time.idle=1.19µs
2026-05-20T16:41:00.208556Z  INFO fff_nvim: Query tracker database initialized at /home/janis/.local/share/nvim/fff_queries
2026-05-20T16:41:00.208562Z  INFO fff_search::file_picker: Spawning background threads: base_path=/home/janis/.local/share/nvim, warmup=true, content_indexing=true, mode=Neovim
2026-05-20T16:41:00.208716Z  WARN fff_search::file_picker: No git repository found for path: /home/janis/.local/share/nvim
2026-05-20T16:41:00.208727Z  INFO walk_filesystem: fff_search::file_picker: new
2026-05-20T16:41:00.208730Z  INFO walk_filesystem: fff_search::file_picker: SCAN: Starting filesystem walk and git status (async)
2026-05-20T16:41:00.210015Z  INFO walk_filesystem:walker_run: fff_search::file_picker: new
2026-05-20T16:41:00.224231Z  INFO walk_filesystem:walker_run: fff_search::file_picker: close time.busy=14.2ms time.idle=5.40µs
2026-05-20T16:41:00.224245Z  INFO walk_filesystem: fff_search::file_picker: SCAN: File walking completed in 14.232014ms for 11016 files
2026-05-20T16:41:00.229021Z  INFO walk_filesystem: fff_search::file_picker: SCAN: Walk completed in 20.29099ms (11016 files, 2093 dirs, chunked_store=0.24MB, files_vec=1.01MB, dirs=0.17MB, FileItem=96B)
2026-05-20T16:41:00.229034Z  INFO walk_filesystem: fff_search::file_picker: close time.busy=20.3ms time.idle=2.75µs
2026-05-20T16:41:00.229041Z  INFO run_post_scan{warmup=true indexing=true}: fff_search::scan: new
2026-05-20T16:41:00.338905Z  INFO run_post_scan{warmup=true indexing=true}: fff_search::scan: close time.busy=110ms time.idle=3.20µs
2026-05-20T16:41:00.338924Z  INFO fff_search::background_watcher: Initializing background watcher for path: /home/janis/.local/share/nvim, mode: Neovim
2026-05-20T16:41:00.374599Z  INFO fff_search::background_watcher: File watcher initialized for 2314 directories (NonRecursive) under /home/janis/.local/share/nvim (aborted_early=false)
2026-05-20T16:41:00.374612Z  INFO fff_search::background_watcher: Background file watcher initialized successfully

The version via :FFFCheckHealth

==============================================================================
fff:                                                                        ✅

fff.nvim ~
- ✅ OK Binary loaded successfully from: /home/janis/.local/share/nvim/lazy/fff.nvim/lua/../target/release/libfff_nvim.so
- ✅ OK fff.nvim version: 0.8.1
- ✅ OK libgit2 available (version: 1.9.2)
- No git repository found in current directory: could not find repository at '/home/janis/.local/share/nvim'
- ✅ OK File picker initialized (ready, 11016 files indexed, base: /home/janis/.local/share/nvim)
- ✅ OK Frecency database operational (30 entries, 52.0 KB, path: /home/janis/.cache/nvim/fff_nvim)
- ✅ OK Query cache database operational (13 query-file mappings, 2 history entries, 56.0 KB, path: /home/janis/.local/share/nvim/fff_queries)
- ✅ OK Image preview available via snacks.nvim
- ✅ OK Filetype icons available via nvim-web-devicons

I don't know but the crashes became even more frequent now and will often occur without ever using kitty-scrollback.nvim. So I will just enable fff in Lazy.nvim via
`enabled = true,' and on the next launch of neovim I will get the segfault errors again. The only thing I can then do is to disable the plugin again with another editor, otherwise neovim won't launch again.

[jemabaris]

Now I was able to launch neovim with fff enabled, left it open, opened a second instance of neovim in another terminal, got the segfault again, but was able to get the FFFOpenLog from the first instance which was still running:

2026-05-20T16:49:12.334287Z  INFO fff_search::log: FFF tracing initialized with log file: /home/janis/.local/state/nvim/fff.log
2026-05-20T16:49:12.334317Z  INFO open_env{db_path="/home/janis/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: new
2026-05-20T16:49:12.334394Z  INFO open_env{db_path="/home/janis/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: close time.busy=72.8µs time.idle=4.72µs
2026-05-20T16:49:12.334428Z ERROR fff_nvim::error: string_value="Failed to start read transaction for frecency database: MDB_READERS_FULL: Environment maxreaders limit reached"

=== CRASH SIGSEGV ===
signal 11
   0: <unknown>
   1: <unknown>

=== CRASH END SIGSEGV ===

[dmtrKovalenko]

very helpful thank you

[dmtrKovalenko]

~~are you sure you are running the latest version? ~~ I see

the other question - do you by any chance have fff-mcp installed? Run fff-mcp --version

[gustav-fff]

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

Root cause: MDB_READERS_FULL from LMDB. The default reader-slot table is 126 entries shared across all processes using the same env. Multiple nvim instances plus GC + background-watcher threads exhaust it, and stale slots from prior unclean exits accumulate (your log shows cleared=30 already). Once env.read_txn() returns the error, it propagates through mlua and unwinds across LuaJIT's C frames — that's the segfault you see (frames lua_error → unwind → libfff_nvim.so + 0x525bc1).

The clear_stale_readers call at open helps but races with concurrent opens, so under enough concurrency you still hit the cap before purge runs.

2026-05-20T16:49:12.334428Z ERROR fff_nvim::error: string_value="Failed to start read transaction for frecency database: MDB_READERS_FULL: Environment maxreaders limit reached"
=== CRASH SIGSEGV ===
signal 11

Fix: bump max_readers in EnvOpenOptions from default 126 to 1024 in crates/fff-core/src/dbs/lmdb.rs:154. Working on fix on triage-bot/issue-498.

[jemabaris]

~~are you sure you are running the latest version? ~~ I see

the other question - do you by any chance have fff-mcp installed? Run fff-mcp --version

I am running whatever version is being downloaded by:

    "dmtrKovalenko/fff.nvim",
    build = function()
      -- downloads a prebuilt binary or falls back to cargo build
      require("fff.download").download_or_build_binary()
    end,

I am also not running the MCP version. Only the neovim plugin.
If you need any further info or if I can help otherwise just let me know.

[jemabaris]

Is there any news on the issue? I'm not able to use fff in its current state as it will always cause these segfaults sooner or later.

[dmtrKovalenko]

Can you try to pull I think it's fixed

[dmtrKovalenko]

Can you please double check if you have a present lock.mdb file in the directory of your database files

Also please run :checkhealth fff

If it's not fixed I'll fix it today

[dmtrKovalenko]

Wait I see that your DB is operational. This is contradicts with the log saying that it exhausts reader slots, I recently fixed a segfault that might be your one

Can you try to pull again, run checkhealth and post the log. This will help significantly