Bug: Windows - Remnant conhost.exe processes exist after fzf-lua search with default configuration followed by Neovim exit

[zshoals]

RTFM Checklist

• 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

Windows 10

Shell

cmd

Neovim version (nvim --version)

NVIM v0.11.3

Fzf version (fzf --version)

0.66.0 (8cdfb23d)

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
• I have not tested with mini.sh (not relevant, requires LSP, Windows, etc)

Fzf-lua configuration

require('fzf-lua').setup({})

Describe the bug / steps to reproduce

Title pretty much covers it; imagine my surprise when I couldn't delete an apparently in use folder, checked with Powertoys File Locksmith and saw 100 instances of conhost.exe attached to it :).

I think this might have to do with how the "hide" profile works? I tested with a very thin init.lua that just has the Lazy package manager bootstrapper and fzf-lua with an empty options table passed in, which from the sounds of things activates the "hide" profile by default. If I execute `require('fzf-lua').setup({ {"fzf-native"} }) to change the profile before calling :FzfLua I don't get these remnant conhosts on Neovim exit and it's shut down properly.

To replicate, I do the following:

1. Start Windows Terminal with a Command Prompt instance open
2. Start Neovim in the target directory via Command Prompt, no file passed
3. Immediately open any fzf-lua picker (I.E. just :FzfLua, and no text entry required)
4. Close the search
5. :qa
6. Say hello to my lonely perpetual conhost friend

The closest issue I could find to this problem was here: #2065. However, the fzf executable does close; it's just conhost.exe that remains active. I also thought this might be an issue with Neovim somehow, but a conhost process created with :terminal in Neovim gets properly shutdown on exit. I did search for any mentions of conhost in the issues and did not find anything.

I'm not super familiar with any of this stuff or the greater Neovim/lua ecosystem, fzf-lua being the culprit is just my best guess at the moment. Hopefully this is not just a dumb oversight on my part.

Video evidence just for fun (the conhost instances are not cleared on Windows Terminal exit):

conhosted_to_death.mp4

[phanen]

neovim/neovim#10783 (comment).

I'm not sure if you wait for a few seconds will it disappear?

[phanen]

Seems a upstream bug. iirc I find this in ci before.

neovim/neovim#12974 (comment)

[zshoals]

neovim/neovim#10783 (comment).

I'm not sure if you wait for a few seconds will it disappear?

Unfortunately no. When I said I had 100 instances of conhost I wasn't exactly joking about that, they were likely there for a few days since I leave my system on most of the time before I noticed and dealt with it.

[ibhagwan]

@phanen, maybe if we add an extra pkill on the process in addition to the jobstop might kill the cohost.exe as well?

[ibhagwan]

@zshoals, can you please test if the 2413 branch solves your issue?

Relevant commit: 199d1ad

[zshoals]

@zshoals, can you please test if the 2413 branch solves your issue?

Relevant commit: 199d1ad

@ibhagwan Unfortunately I'm still getting leftover conhost processes even with this change, sorry. I double checked and verified that the repo was on 199d1ad too just in case something went wrong with Lazy.

[ibhagwan]

@ibhagwan Unfortunately I'm still getting leftover conhost processes even with this change, sorry. I double checked and verified that the repo was on 199d1ad too just in case something went wrong with Lazy.

Ty for testing @zshoals, I’ll have to do some digging and reproduce this myself, wasn’t familiar with cohost.exe or used Windows for many years now.

Any input from your debugging will be valuable.

I also thought this might be an issue with Neovim somehow, but a conhost process created with :terminal in Neovim gets properly shutdown on exit.

Will you be able to test this again albeit slightly different?

1. Run :sp | term (open term in a split)
2. Run fzf in the term window and do not close it
3. Press ctrl-\ + ctrl-n to go to normal mode and ctrl-w+w to return to your other buffer
4. Press ctrl-w+o to hide the term buffer
5. :qa! and see if you have a lingering cohost.exe

[zshoals]

@ibhagwan Unfortunately I'm still getting leftover conhost processes even with this change, sorry. I double checked and verified that the repo was on 199d1ad too just in case something went wrong with Lazy.

Ty for testing @zshoals, I’ll have to do some digging and reproduce this myself, wasn’t familiar with cohost.exe or used Windows for many years now.

Any input from your debugging will be valuable.

I also thought this might be an issue with Neovim somehow, but a conhost process created with :terminal in Neovim gets properly shutdown on exit.

Will you be able to test this again albeit slightly different?

1. Run `:sp | term` (open term in a split)

2. Run fzf in the term window and do not close it

3. Press `ctrl-\ + ctrl-n` to go to normal mode and `ctrl-w+w` to return to your other buffer

4. Press `ctrl-w+o` to hide the term buffer

5. `:qa!` and see if you have a lingering cohost.exe

Ah, doing that does indeed leave lingering conhosts around. These remain even after exiting Windows Terminal.

Sorry, was not intending to mislead you before...

[ibhagwan]

Ah, doing that does indeed leave lingering conhosts around. These remain even after exiting Windows Terminal.

That would indicate an upstream issue.

Now if we can find a workaround in the neovim term without fzf-lua we can apply the same workaround within fzf-lua.

I’m wondering why the process kill (+children) in the git branch did not work, maybe we have to force “accept” or send ctrl-c to the Fzf process before terminating the term buffer - will you be able to test that and see if that helps with the cohost.exe issue?

Sorry, was not intending to mislead you before...

No need to apologize your bug report was very detailed and helpful :)

[ibhagwan]

I’m also thinking it might be just with a hidden window / term buffer so try to do the same testing without hiding the term buffer

[zshoals]

@ibhagwan If I ctrl-c in the Neovim generated terminal or simply accept an entry in fzf when I execute it from the terminal, the conhost process that's generated is correctly closed on Neovim exit.

I also tried without hiding the terminal buffer while leaving fzf up in the Neovim generated terminal, however, this made no difference and there was a leftover conhost process in this case.