Exiting neovide on windows leaves orphaned neovim processes around

[kareigu]

Describe the bug
Closing neovide by any normal means results in 2 neovim processes being left running indefinitely.
After a few days I have had upwards of 10 that are taking up a sizeable amount of memory for nothing.

To Reproduce
Steps to reproduce the behavior:

1. Start neovide
2. Close it
3. Look at task manager, 2 neovim processes are still running

Expected behavior
Close down the neovim processes during teardown.

Screenshots
If applicable, add screenshots to help explain your problem.


After closing neovide with :q

Desktop (please complete the following information):

• OS: Windows 11 22635.3140
• Neovide Version: 0.12.2
• Neovim Version: 0.10.0-dev-2465+ga7788c2e2 , latest nightly on scoop at this time

Please run neovide --log and paste the contents of the .log file created in the current directory here:

Log from receiving Q KeyEvent

TRACE [neovide::window::keyboard_manager] KeyEvent {
    physical_key: Code(
        KeyQ,
    ),
    logical_key: Character(
        "q",
    ),
    text: Some(
        "q",
    ),
    location: Standard,
    state: Pressed,
    repeat: false,
    platform_specific: KeyEventExtra {
        text_with_all_modifers: Some(
            "q",
        ),
        key_without_modifiers: Character(
            "q",
        ),
    },
}
TRACE [neovide::window::keyboard_manager] Key pressed q ModifiersState(0x0)
TRACE [neovide::channel_utils] UICommand Serial(Keyboard("q"))
TRACE [neovide::bridge::ui_commands] In Serial Command
TRACE [neovide::bridge::ui_commands] Keyboard Input Sent: q
TRACE [neovide::bridge::handler] Neovim request: "neovide.quit"
INFO [neovide::running_tracker] Quit with code 0: Quit from neovim
DEBUG [neovide::settings::window_size] Saved Window Settings: {"window":{"Windowed":{"position":{"x":370,"y":201},"pixel_size":{"width":1838,"height":1025},"grid_size":{"width":183,"height":51}}}}
DEBUG [neovide::settings::window_size] Saved Window Settings: {"window":{"Windowed":{"position":{"x":370,"y":201},"pixel_size":{"width":1838,"height":1025},"grid_size":{"width":183,"height":51}}}}
DEBUG [neovide::settings::window_size] Saved Window Settings: {"window":{"Windowed":{"position":{"x":370,"y":201},"pixel_size":{"width":1838,"height":1025},"grid_size":{"width":183,"height":51}}}}
TRACE [neovide::bridge::handler] Neovim notification: "redraw"
TRACE [neovide::channel_utils] neovim_handler MouseOff
TRACE [neovide::channel_utils] neovim_handler Flush
TRACE [neovide::editor] Image flushed
TRACE [neovide::editor] send_batch

[fredizzimo]

This was exactly what worried me when we merged this:

• fix: fix hang on neovim exit #2265

But I had no other choice than to merge it, since the reports of hangs were getting out of control, and I'm unable to reproduce it and therefore debug it myself. But we really need someone that can repeat the hangs to find the root cause and make a proper fix.

@sid-6581 for awareness.

Based on the logs in this case it looks like we correctly get the message back from Neovim that it's about the quit, along with the exit code, which is sends after the point of no-return, where it should exit no matter what. But we actually receive another draw command from Neovim after that. Note that Neovim might actually send the messages in the correct order, but because we process them in different places and GUI events and RPCs are, they can appear out of order for us.

After that happens, it tries to send a message back to our main loop, but since that has already finished, this may our may not cause a hang without the workaround of #2265, it depens a lot on how thread safe the wnit code is here, and if EventLoopProxy.send() is guaranteed to either send the message or finish with an error. This is a clear bug in the Neovide code, that could have caused an exit hang before, but based on the description of @sid-6581, that's not what was happening.

What we should do here is to wait in the main loop until Neovide has quit, and everything is processed before we exit the loop. That also requires us to actually wait until Neovide has quit, so we know that there's no new messages incoming.

It also seems like Neovim itself hangs after that for an unknown reason, it might be that it's stuck waiting for something from Neovide, which never arrives because we prematurely quit, or it might be something else. In either case, Neovim should be able to detect that Neovide is gone and quit, so it is a Neovim bug in any case. But even in that case, I would prefer that Neovide also hangs along with it, so that the user can kill both processes manually. Leaking processes is one of the most unfriendly things to do, since the user need to be quite technical to figure out what's going on. It can also do things like lock Neovim swapfiles, that you are then unable to delete because they are still open in the phantom instances.

[sid-6581]

@fredizzimo speaking of leaking processes, this was after one day of working:

(Yes, I open and quit neovide a lot, so that's why I'm probably experiencing these issues more frequently than most.)

neovide didn't hang while I was working yesterday, so as far as neovide was concerned, neovim told it to quit and neovide obliged, but then the neovim processes just stuck around. Haven't had a chance to debug this yet.

[kareigu]

But I had no other choice than to merge it, since the reports of hangs were getting out of control, and I'm unable to reproduce it and therefore debug it myself. But we really need someone that can repeat the hangs to find the root cause and make a proper fix.

I think it was the right call, I went back to using neovim on the terminal for a while because I was getting those hangs every time I closed out of neovide.

Did some quick testing with the old code now and this is still the case on my machine.
Closing out of neovide will trigger a stall every single time and leave the running neovim processes behind.

[konosubakonoakua]

Same here

[fredizzimo]

It's not an universal problem, I ran this crazy stress test in powershell
0..1000 | ForEach-Object { neovide -- --clean --cmd sleep --cmd quit }, launching 1000 instances at the same time, and all of them exited properly.

WARNING! This can completely lock up your computer, so test with a smaller number first! On my system even the mouse cursor started to lag, but all of the instances eventually exited correctly.

This was:

• My Direct3D branch of Neovide,
• Neovim 0.9.5 installed by scoop (so it actually launches two processes),
• Windows 11 21H2 (22000.2777), yes, it's very old on this machine, but I have used the latest feature packs without any issues on other machines.

[fredizzimo]

I also tested with the downloaded 0.12.2 from the releases and Neovim nightly installed by scoop. And no problem with that either launching 1000 instances simultaneously.

This could be something in the configuration, or some other trigger, so it would be good if someone could try the same command (10 or 100 instancers might be enough if you can easily repeat it). And if it does not repeat, try to create a minimal init.lua that triggers it.

[kareigu]

Tried that with 10, 100 and 1000 instances (0.12.2 scoop), no processes left around.
Seems like it's something in my config causing the stall then.

[kareigu]

As a test I ended removing my whole nvim-data directory from local appdata to have a clean setup of my lazy.nvim packages.
Secondly I updated neovim to the latest nightly again.
This seems to have somehow fixed the issue with all neovim processes exiting correctly along with neovide.

[fredizzimo]

@kareigu, that was probably the shada issue reported here then #2182 (comment)

Maybe we can replicate it be creating zero bytes files.

For anyone that are having the problem, don't delete the directory, rename it and save the contents, so we can potentially analyze it and see what the problem is, if it's possibly something else.

BTW, a better command for testing is
0..100 | ForEach-Object { neovide.exe -- --clean -c "call timer_start(1000, {id -> execute('quit')})"} which actually properly launches the GUI

[kareigu]

Most likely yes, I had that issue with neovim not closing without pressing a key in wezterm.

[pidgeon777]

Deleting the zero byte .shada files in nvim-data\shada fixed the issue for me.

Also, when the issue occurred I had to press a random key after sending the close signal to Neovide to actually "close" it.

[ronitnallagatla]

Having a similar issue on linux. But it seems to occur randomly.

If I open a file using Neovide, edit it, and :wq out of Neovide. The next time I open the file, I get a "swap file exists" prompt because the nvim process is still running.

[fragilebody]

I had this issue on macOS as well.
Deleting the .shada files seemed to fix the issue for now.

[fredizzimo]

If someone encounter the problem with the zero bytes shada files, it would be nice if you took a backup of the files before deleting them, so that the problem can be repeated by some developer.

I tried to replicate the issue by creating a zero byte main.shada file, but that does not seem to cause any issues. And as far as I know that's the only shada file nvim creates by itself. So, it might very well be possible that it's some plugin that does not deal with zero bytes shada files, but we need to figure out which.

[fredizzimo]

I managed to repeat it, by writing a shada file with the content corrupted, a zero-byte file was not enough apparently.

Edit: And running the terminal neovim reveals that there should be an error message at the exit, but Neovide does not show it and therefore also never pass the enter key to neovim, so it will never quit.

[fredizzimo]

I think we will need to revert @sid-6581's

• fix: fix hang on neovim exit #2265

And make an even stronger guarantee, don't exit any of our processing loops or main event loop until we detect that the pipe is closed on the other side. We can't really use the process exit as an indication, since it does not work with remote instances.

Before that can be done though, we need to fix the common hangs of the clipboard tools in Neovim. And maybe the issue @sid-6581 had, unless that too was caused by one end of the communication closing too early.

[fredizzimo]

This will be fixed by

• fix!: Perform a clean exit again #2463

So. if it still hangs for you, it would be good to verify that the fix works.