Bug: Orphan processes

[Fuuruko]

RTFM Checklist

• [x] I have searched exisiting issues / discussions
• [ ] I have read the Wiki including the Advanced section
• [ ] I have read man fzf / I am well versed in shell fzf

Operating system

Linux

Shell

zsh

Neovim version (nvim --version)

NVIM v0.11.1

Fzf version (fzf --version)

0.62.0 (d226d841)

Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))

nil

Is the problem reproducible with mini.sh?

• [ ] My issue is reproducible with mini.sh
• [ ] My issue IS NOT reproducible with mini.sh
• [x] I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup({
  'hide',
  'default-title',
  winopts = {
    fullscreen = true,
    preview = {
      -- default = 'bat',
      delay = 100
    }
  },
  previewers = {
    builtin = {
      title_fnamemodify = function(s)
        return vim.fn.fnamemodify(s, ':.')
      end
    }
  }
})

Describe the bug / steps to reproduce

Over time, while I'm working, such orphan(?) processes are created. If i kill them plugin may stop working.

[nenahp]

hide means fzf process is not killed when hit enter/esc. Only when you switch to new picker.

Ideally one nvim instance would hold at most one fzf process. So how many nvim you open when you find so many fzf instance?

You can use :=vim.api.nvim_list_chans() to confirm if there're dangling processes.

IIRC very occasionally I can see two fzf process exists (maybe when some error happened in fzf_exec, so the fzf process is believed to be died/killed but actually it's not.)

[Fuuruko]

Ideally one nvim instance would hold at most one fzf process. So how many nvim you open when you find so many fzf instance?

3 instances. Screenshot made not right now but still I don't have more that 5 opened

You can use :=vim.api.nvim_list_chans() to confirm if there're dangling processes.

Ok, I kill other nvim instances and there's 5 processes in nvim, though only 3 in system monitor.

[ibhagwan]

@Fuuruko, would you be able to test and provide a reproducible scenario where the Fzf process remains orphan (cancelling with ctrl-c? Switching pickers? Custom actions)?

[Fuuruko]

I'm not sure I can provide it right know as I don't know what cause it. I'll try to add some debug code where killing happen like this

for k, v in pairs(vim.api.nvim_list_chans()) do
  if v.buffer == fzf_bufnr then
    vim.print("FZF DEBUG " .. fzf_bufnr .. " " .. opts.winopts.title)
  end
end

here

https://github.com/ibhagwan/fzf-lua/blob/a3e614173397e947bc2755c8c90633ff57f93c1e/lua/fzf-lua/core.lua#L450

At least it will tell what picker may cause it. Is there something else that can be useful that i should add?

[ibhagwan]

At least it will tell what picker may cause it. Is there something else that can be useful that i should add?

Which picker and also which series of steps to take to orphan it would be great (press enter, open in tab, resume, ctrl-g, etc).

[ibhagwan]

@Fuuruko, would you be able list the orphan process args? This can give us a clue are these processes enumerating data for the pickers or preview/execute-silent callbacks.

Try to capture the entire process line/args and post some of these here? For example if we see shell_helper.lua on the args we know it’s an fzf-lua callback run by fzf itself.

[ibhagwan]

@Fuuruko, the latest refactoring changed in a great way how fzf-lua provides fzf with data, it's now all done unifromally with a neovim wrapper shell command (lua script with nvim -l), can you update the plugin to the latest commit, give it a run and see if you're still having orphan processes?

If you do, please provide the entire process arguments from ps -ef as that will help me debug the issue further.

[ibhagwan]

Closing as I don’t believe this is relevant anymore, due to the big content command refactor process ownership is handled by fzf which should kill all sub processes on exit.

Feel free to reopen and I’m wrong and you have more info (the process args should tell me the source of the process).