[Bug]: FFF segfaults when launching neovim from a deleted directory.

[mkblast]

Which fff frontend?

Neovim plugin (fff.nvim)

has logs

2026-06-27T10:19:04.124407Z  INFO ThreadId(02) fff_search::log: FFF tracing initialized: /home/karim/.local/state/nvim/logs/fff+1782555544+34397.log (pid=34397, retain_runs=20)
2026-06-27T10:19:04.124456Z  INFO ThreadId(02) open_env{db_path="/home/karim/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: new
2026-06-27T10:19:04.124642Z  INFO ThreadId(02) open_env{db_path="/home/karim/.cache/nvim/fff_nvim"}: fff_search::dbs::lmdb: close time.busy=176µs time.idle=8.59µs
2026-06-27T10:19:04.124767Z  INFO ThreadId(02) fff_nvim: Frecency database initialized at /home/karim/.cache/nvim/fff_nvim
2026-06-27T10:19:04.124777Z  INFO ThreadId(02) open_env{db_path="/home/karim/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: new
2026-06-27T10:19:04.124929Z  INFO ThreadId(02) open_env{db_path="/home/karim/.local/share/nvim/fff_queries"}: fff_search::dbs::lmdb: close time.busy=147µs time.idle=4.06µs
2026-06-27T10:19:04.125054Z  INFO ThreadId(02) fff_nvim: Query tracker database initialized at /home/karim/.local/share/nvim/fff_queries
2026-06-27T10:19:04.125108Z  INFO ThreadId(02) fff.trace{trace_id="9b62b9d694f8de20" label="picker"}: fff_search::log: new
2026-06-27T10:19:04.125114Z  INFO ThreadId(02) fff_search::file_picker: Spawning background threads: base_path=/home/karim, warmup=true, content_indexing=true, mode=Neovim
2026-06-27T10:19:04.126254Z  WARN fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}: fff_search::file_picker: No git repository found for path: /home/karim
2026-06-27T10:19:04.126288Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem: fff_search::file_picker: new
2026-06-27T10:19:04.126293Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem: fff_search::file_picker: SCAN: Starting filesystem walk and git status (async)
2026-06-27T10:19:04.128031Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem:walker_run: fff_search::file_picker: new
2026-06-27T10:19:04.378043Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem:walker_run: fff_search::file_picker: close time.busy=250ms time.idle=15.4µs
2026-06-27T10:19:04.378067Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem: fff_search::file_picker: SCAN: File walking completed in 250.042382ms for 39198 files
2026-06-27T10:19:04.432300Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem: fff_search::file_picker: SCAN: Walk completed in 306.003354ms (39198 files, 3693 dirs, chunked_store=0.77MB, files_vec=3.59MB, dirs=0.34MB, FileItem=96B)
2026-06-27T10:19:04.432336Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:walk_filesystem: fff_search::file_picker: close time.busy=306ms time.idle=5.89µs
2026-06-27T10:19:04.432351Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:run_post_scan{warmup=true indexing=true}: fff_search::scan: new
2026-06-27T10:19:05.766708Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}:run_post_scan{warmup=true indexing=true}: fff_search::scan: close time.busy=1.33s time.idle=4.99µs
2026-06-27T10:19:05.766748Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}: fff_search::background_watcher: Initializing background watcher for path: /home/karim, mode: Neovim
2026-06-27T10:19:05.891164Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}: fff_search::background_watcher: File watcher initialized for 4085 directories (NonRecursive) under /home/karim (aborted_early=false)
2026-06-27T10:19:05.891185Z  INFO fff-scan fff.trace{trace_id="9b62b9d694f8de20" label="picker"}: fff_search::background_watcher: Background file watcher initialized successfully

Description

It's not a big issue to begin with. However, I'll report it nonetheless.
steps:

• mkdir test
• cd test
• rmdir test (in another terminal.)
• Launch nvim, FFF will segfault.

Small side note:
The log path is ~/.local/state/nvim/logs not ~/.local/state/nvim/log

Thanks for the plugin!

[dmtrKovalenko]

the reason for this is the cache we use, let me see if we can intercept the deletion of the root folder on it's own and shut down the picker

[gustav-fff]

[triage-bot] NEEDS INFO:

Cannot reproduce on macOS (Darwin 25.5.0, nvim v0.12.3) with steps as written — mkdir test && cd test && rmdir test (from another shell) → launch nvim → fff initializes on $HOME and does not crash. Log shows clean init through Background file watcher initialized successfully, same as your attached log.

The log you pasted stops at successful init and does NOT contain the SIGSEGV banner that our handler writes on crash (=== CRASH SIGSEGV (fff) ===). Two possibilities: (a) the banner is missing because the log was truncated before paste, or (b) neovim exited from a non-SIGSEGV cause and it's not actually fff crashing.

To triage, please attach:

1. Full log file after a crash run (~/.local/state/nvim/logs/fff+<ts>+<pid>.log) — specifically the tail that includes the === CRASH SIGSEGV === block if present.
2. nvim --version and OS (Linux distro + kernel).
3. getcwd behavior after the rmdir: cd /tmp && mkdir t && cd t && (cd /tmp && rmdir /tmp/t) && pwd; env | grep PWD — paste output. Neovim's cwd resolution differs from the shell here and matters for base_path.
4. Exit code / any stderr from nvim after crash (nvim 2>err.log).

Re: log-path typo — confirmed, crates/fff-core/src/log.rs writes to stdpath('log') which is ~/.local/state/nvim/logs on Linux (nvim ≥ 0.10), reporter typo noted, not a bug.

Honk-Honk 🪿

[dmtrKovalenko]

@gustav-fff no I think he means that fff was launched via neovim instance and then this directory got removed

[mkblast]

@gustav-fff no I think he means that fff was launched via neovim instance and then this directory got removed

To be more precise, It only segfaults when:
First: deleting the directory.
And Then: Launching neovim.

If neovim is already open, it won't segfault it will only show no files when opening the picker...

[dmtrKovalenko]

@mkblast this is strange. I do not understand how this is possible, if you remove the folder and then you open vim at a folder it will just start the sync on the parent folder. Your logs showing this it starts indexing your parent /home/karim but there is no information about the segfault in your log

[mkblast]

Check this short vid:
https://github.com/user-attachments/assets/8f55cbb8-612b-4df1-88b4-1956a05d6f87

And also the logs were from 2026-06-27. I checked again, and the log file is not updated.

[dmtrKovalenko]

do you use lazy = false?

[mkblast]

do you use lazy = false?

I do:

return {
    "dmtrKovalenko/fff.nvim",

    build  = function()
        require("fff.download").download_or_build_binary()
    end,

    lazy   = false,

    config = function()
        local fff = require("fff")

        fff.setup({
            base_path       = vim.fn.getcwd(),
            prompt_vim_mode = true,
            layout          = {
                prompt_position = 'top',
            },
            grep            = {
                enable_filename_constraint = true,
            },
            debug           = {
                enable      = true,
                show_scores = true,
            }
        })

        local map          = vim.keymap.set
        local default_opts = { noremap = true, silent = true }

        local function get_current_word()
            return table.concat(vim.fn.getregion(vim.fn.getpos("v"), vim.fn.getpos(".")))
        end

        map("n", "<leader>f", function() fff.find_files() end, default_opts)
        map("n", "<leader>/", function() fff.live_grep() end, default_opts)
        map("n", "<leader>r", function() fff.resume() end, default_opts)
        map("n", "<leader>F", function() fff.find_files({ resume = true }) end, default_opts)
        map("n", "<leader>?", function() fff.live_grep({ resume = true }) end, default_opts)

        map("n", "<leader>*", function()
            fff.live_grep({ query = vim.fn.expand("<cword>") })
        end, default_opts)

        map({ "x", "v" }, "<leader>*", function()
            fff.live_grep({ query = get_current_word() })
        end, default_opts)
    end
}

[gustav-fff]

[triage-bot] DIRECTED:

@dmtrKovalenko your read got contradicted by the reporter one comment later — they reconfirmed the flow is mkdir/cd/rmdir → launch nvim, not nvim first → rmdir. That's the flow I already couldn't reproduce on macOS.

Two things stand out from the reporter's log + video combo:

1. Log is stale (2026-06-27, and reporter confirms it isn't updated on repro runs). Either init_tracing never runs on the failing session, or fff dies before log::init_tracing opens the sink at crates/fff-core/src/log.rs:244-247. Note: reporter has lazy_sync = true (default, lua/fff/conf.lua:215), so plugin/fff.lua:11 deliberately does NOT call ensure_initialized on UIEnter — first init is deferred to <leader>f. If the crash truly fires on launch (before any picker command), fff hasn't been touched yet — suggests the video may actually show the crash on first find_files() after launch, not on launch itself. Worth clarifying.

2. No SIGSEGV banner despite the handler at crates/fff-core/src/log.rs:54-69. On Linux the handler runs libc::write(2, ...) unconditionally to stderr — so even without a log file, nvim 2>err.log would capture the banner. Its absence means either (a) the crash isn't in the rust extension (SIGSEGV from LuaJIT or another native lib), or (b) fff was never loaded, or (c) the process died from a non-SIGSEGV signal (SIGABRT via panic = abort? we're panic = unwind per Cargo.toml, but worth checking).

Reporter-side asks that would resolve this in one round:

# 1. reproduce with stderr captured — banner should land here even without log
cd /tmp && mkdir t && cd t && (cd /tmp && rmdir t)
nvim 2>/tmp/fff-err.log
# then in nvim: <leader>f
# quit, then: cat /tmp/fff-err.log

# 2. exit signal — is it SIGSEGV at all?
coredumpctl list nvim | tail -5
coredumpctl info <PID>   # look for "Signal: 11 (SEGV)" vs "Signal: 6 (ABRT)"

# 3. native backtrace
coredumpctl gdb nvim     # then: bt full

I'll hold off on any code changes until reporter confirms whether the crash is actually in fff (banner present) or elsewhere (banner absent + non-SEGV signal).

Honk-Honk 🪿