[Bug]: neovim plugin crashes neovim when opening a file

[SyntaxError2505]

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

This is the resulting logfile:

fff.log

Description

Sometimes (no real percentage but can happen 100% of the time on some days and work cleanly on others) when opening a project in neovim and opening a file (using neo-tree), a crash message appears and neovim exits to a shell.

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.

Normally just reopening neovim after that allows for unobstructed work but when opening a new directory/project, it can happen again.

[hiSandog]

A Neovim crash report needs a very small reproduction to be actionable. Could you include Neovim version, plugin manager, the exact fff config, and whether it still crashes with nvim --clean plus only this plugin loaded? If it is a native crash, a backtrace or the last few log lines before opening the file would be especially helpful.

[SyntaxError2505]

Neovim Version: v0.12.2
Lazy plugin manager
FFF version: 0.9.7-nightly.e0a9e08

FFF spec:

return {
  'dmtrKovalenko/fff.nvim',
  build = function()
    -- this will download prebuild binary or try to use existing rustup toolchain to build from source
    -- (if you are using lazy you can use gb for rebuilding a plugin if needed)
    require("fff.download").download_or_build_binary()
  end,

  opts = { -- (optional)
    debug = {
      enabled = true,     -- we expect your collaboration at least during the beta
      show_scores = true, -- to help us optimize the scoring system, feel free to share your scores!
    },
  },
  -- No need to lazy-load with lazy.nvim.
  -- This plugin initializes itself lazily.
  lazy = false,
}

FFF keybinds (loaded after spec):

-- FFF (Grep and search)
vim.keymap.set("n", "<leader>ff", function() require("fff").find_files() end, {desc = "Find files"})
vim.keymap.set("n", "<leader>fg", function() require("fff").live_grep() end, {desc = "Grep files"})
vim.keymap.set("n", "<leader>fz", function () require("fff").live_grep( {grep = { modes = { "fuzzy", "plain" }}}) end, {desc = "Fuzzy Grep files"})
vim.keymap.set("n", "<leader>fc", function() require("fff").live_grep({ query = vim.fn.expand("<cword>")}) end, {desc = "Grep current word"})

I cannot seem to replicate it. The issue persists for days and dissapears. I do not mean what you mean by native crash but it stops all of neovim, the ui still stays and the place of the cursor is random, a SIGSEGV message appears showing the text in the description.

[gustav-fff]

[triage-bot] NEEDS INFO:

The attached fff.log contains only startup init lines and stops well before any crash — no panic, no SIGSEGV marker, no backtrace. Without a stack trace this is not actionable, and neovim v0.12.2 + fff 0.9.7-nightly.e0a9e08 has no known deterministic segfault path we can pin down from the description alone.

@SyntaxError2505 please provide:

1. A backtrace. Launch nvim under a debugger or enable core dumps:

   ulimit -c unlimited
   nvim <path>
   # after crash:
   coredumpctl gdb           # or: gdb nvim <core-file>
   (gdb) thread apply all bt full

   Paste the full output (all threads).

2. Full fff.log captured during a session that actually crashes (not a clean session). With debug.enabled = true the crash handler writes === CRASH SIGSEGV === + frames to the log — the shared log does not contain that section, so it is from a non-crashing run.

3. OS + arch (uname -a), and the directory layout / rough file count of the project where it reproduces on "bad days".

4. Whether the crash still happens with nvim --clean -u <minimal_init.lua> loading only fff.nvim.

Similar past reports (#498, #567, #534) all required a real backtrace before root cause could be found.

Honk-Honk 🪿

[dmtrKovalenko]

your log file doesn't really surface the panic log

[SyntaxError2505]

I cannot find a === CRASH SIGSEV === in my .local/state/nvim where I see fff logfiles. I have debug on consistently so this is a mystery to me. If the issue happens again, I'll be sure to search in the logfiles again. If it helps, I have noticed that it tends to happen on new neovim installations and just goes away after some time

[dmtrKovalenko]

Makes sense. Then I will close the issue for now, one you found that this happened just opne the last modified fff log from the folder and send it to me directly or to this issue (but tag me)

[dmtrKovalenko]

@gustav-fff just for my own sanity can you try out a few differnet ways to reproduce this issue around, maybe check if the db could be in the deadlock state or something

[gustav-fff]

[triage-bot] DIRECTED:

Investigated repro/deadlock angles. One hard finding, rest inconclusive.

Why the crash banner is not in the reporter's log — crates/fff-core/src/log.rs:38 opens the sigsegv log fd with .append(true).open(path) (no create(true)) and runs at log.rs:225, before init_tracing creates the writer file at log.rs:237. On a first-ever session (fresh nvim install, exactly what @SyntaxError2505 reported "tends to happen on new neovim installations"), the file does not exist yet, the open silently fails, LOG_FD stays -1, and:

libc::write(2, BANNER.as_ptr().cast(), BANNER.len());
let log_fd = LOG_FD.load(Ordering::Relaxed);
if log_fd >= 0 {                     // false — stays -1
    libc::write(log_fd, BANNER.as_ptr().cast(), BANNER.len());
}

So the banner lands on stderr only; nvim discards that on exit-to-shell. This directly explains why no === CRASH SIGSEGV (fff) === section ever showed up in the attached fff.log. Fix + PR: #648.

Deadlock check — could not synthesize a deterministic hang against main. crates/fff-core/tests/lmdb_stale_lock_deadlock.rs already exercises the paths that historically caused it (query_tracker_many_parallel_open_close_same_path_readers, query_tracker_parallel_open_write_close_same_path, query_tracker_sequential_reopen_loop_same_path) and they pass. track_access is off the main thread (crates/fff-nvim/src/lib.rs:531), so even if the LMDB writer mutex were held by a stuck sibling, the neovim main thread would not block — it would just leak worker threads. The commented-out frecency_open_blocks_on_fresh_db... test at lmdb_stale_lock_deadlock.rs:423 notes heed 0.22's unnamed-db creation "may not require writer mutex in all cases", so a deadlock through the frecency init path is possible but has not been reproduced here.

What is still needed from the reporter — even with #648 the underlying SIGSEGV needs frames. Once merged, next crash's fff+<ts>+<pid>.log will contain the === CRASH SIGSEGV === section; coredumpctl gdb / gdb nvim <core> on the corresponding core file then gives the frames. Without that we are still guessing between (a) an arena/index race similar to #569 (overflow arena update after empty initial scan — regression test at crates/fff-core/tests/overflow_frecency_segfault.rs), (b) a rare LMDB env-open race on macOS (crates/fff-core/src/dbs/lmdb.rs:110 acknowledges concurrent mdb_env_open fixably races and retries), or (c) something in the file-picker background watcher lock ordering.

Honk-Honk 🪿