Vim: Multiple instances of nvim.exe process

[ppasieka]

• Click thumbs-up 👍 on this issue if you want it!
• Click confused 😕 on this issue if not having it makes VSCodeVim unusable.

The VSCodeVim team prioritizes issues based on reaction count.

---

Maybe BUG REPORT:

It seems that nvim.exe proces is spawn for each tab I edit. These processes are still running even I close all tabs (VS Code is still running but without any opened tab). This is not a big problem ... but after 8 hours of work my Task Manager looks like this

Environment:

• VSCode Version: 1.16.1
• VsCodeVim Version: 0.10.1
• OS: Windows 10

What did you expect to happen:
Some cap on number of active nvim processes. e.g max 10 is kept running. Oldest are closed

How to reproduce it:

Open multiple files. Then close them. Keep your editor running

[Serabe]

I think I'm seeing a similar problem in macOS where nvim opens a lot of files without closing them.

Running sudo lsof -n | cut -f1 -d' ' | uniq -c | sort -r | head I get:

•100% ➜ sudo lsof -n | cut -f1 -d' ' | uniq -c | sort -r | head
1312 nvim
 656 Google
 604 Google
 497 watchman
 481 postgres
 433 LaunchBar
 429 nvim
 423 Code\x20H
 421 Dropbox
 320 nvim

I can reproduce using the above reproduction. Same VSCode Version, same VsCodeVim Version, macOS 10.12.6 (16G29).

[Chillee]

:( This is just fairly lazy coding by my part. The right thing to do is to multiplex all of the files in one neovim instance. However, due to a couple more things you have to handle (what happens if all buffers are closed, you need to manage switching between buffers properly), I decided to sandbox each vscode tab in one neovim instance. Considering that anybody using VSCode is probably not using it in a very memory constrained situation (not to mention that anybody who needs the memory can just turn off vim.enableNeovim), I considered it acceptable.

The not cleaning up neovim instances properly is more concerning. I'll try and take a look at that.

[alexander-lazarov]

I can confirm that this is still a problem, not a big deal though. Here is my current setup:

macOS 10.13.2
VSCode 1.19.0
VSCodeVim 0.10.6

Closing VSCode and running killall -9 nvim will get rid of all the orphaned nvim processes.

[hraban]

Can confirm on mac; I have 109 zombie nvim processes open. I rarely restart / shutdown, so this is probably a few weeks' worth of semi daily vscode use. Note that VScode is completely quit at the moment, so this is a full on bug, not just expected operation.

re @Serabe's command: If your goal is to count filedescriptors on mac, you'll want to sort before uniq:

$ sudo lsof -n +c 0 | cut -f1 -d' ' | sort | uniq -c | sort -nr | head
3594 nvim
1598 plugin-container
 716 iconservicesagent
 499 firefox
 433 Finder
 311 UserEventAgent
 282 Dock
 207 AppleSpell
 183 mds_stores
 166 2BUA8C4S2C.com.agilebits.onepas

But note that this is treacherous; you're counting mostly just loopback connections, dynamic libs and plugin sockets. If you want to see the actually open files:

$ sudo lsof -n +c 0 -c nvim | grep /Users/ | grep -v /.vscode/extensions/
nvim    65830 hraban   17u     REG                1,5      12288 7599052 /Users/hraban/.local/share/nvim/swap/%Users%hraban%.vscode%extensions%vscodevim.vim-0.10.13%out%src%neovim.swp

which is a lot less.

P.S.: Never kill -9 when a normal kill will do. You really don't want to be sending SIGKILL to processes handling important data.

[jpoon]

@chillee: Do we need a neovim exe for every mode handler (ie. text editor) = https://github.com/VSCodeVim/Vim/blob/master/extension.ts#L37?

Looks like we don't ever kill the child processes :). A simple approach could be to have the neovim class implement vscode.disposable and then push it up to the extensionContext.subscriptions to let vscode handle the disposal properly.

[jpoon]

Actually, maybe we could move the initialization of neovim to ModeHandler and then add the process.kill in the existing dispose() function.

[Chillee]

@jpoon Well, we don't necessarily need a neovim exe for each mode handler, but I think it's pretty risky/requires more work if we handle everything with one instance. Otherwise, we run the risk of replacing text in user's buffers.

I think your second comment sounds like the way to go.