nvim-lua / plenary.nvim

plenary: full; complete; entire; absolute; unqualified. All the lua functions I don't want to write twice.
MIT License
2.77k stars 288 forks source link

bug: path.lua too many files open #373

Open shawnyu5 opened 2 years ago

shawnyu5 commented 2 years ago

I've been getting too many files open error a bit more often lately, which crashes my entire neovim

image

Even after setting the ulimit via ulimit -n 4096, as suggested by #351, the error still persisted, though not as often.

I got the above error by opening 2 tabs, one with :terminal, running zsh. And the other contains 2 js files in a split. After switching between the 2 tabs consecutively about 10 times, the above error popped up.

My hypothesis is that every time I visit a buffer, old or new, path.lua stores the path to the file somewhere. And visiting the same files a few times causes that list to get really large, even though there has not been any new buffers opened, which causes it to panic and crash neovim. This is just a guess tho, as I'm not familiar with plenary's code base.

Neovim version:

NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

Running on Linux, endeavour.

miversen33 commented 2 years ago

I don't think plenary cold stores information related to your current session. I believe harpoon is used with caching things but honestly I think this may actually be unrelated to both and actually related to your shell process having too many files open. I get a similar error if I'm not good about closing out Tmux sessions (though in my case it doesn't always manifest itself in neovim).

Can you reliably reproduce your issue, and provide a minimal configuration file for said reproduction? Right now a best guess is just a shot in the dark and we'd really have no idea where to start

shawnyu5 commented 2 years ago

Hmm, right now I can't seem to reliably reproduce the bug. It just happens randomly. I guess I'll mess around with it. I also do run tmux, so that might be the cause of the issue, I'll keep an eye on my tmux usage and see what happens.

miversen33 commented 2 years ago

Just to provide a bit more context, the line that is listed in your error is as follows

local fd = assert(uv.fs_open(self:expand(), flag, mode))

Basically, "get a file descriptor from libuv". The error provided EMFILE is a linux error thrown by the errno.h header

EMFILE Too many open files (POSIX.1-2001).  Commonly caused by
              exceeding the RLIMIT_NOFILE resource limit described in
              [getrlimit(2)](https://man7.org/linux/man-pages/man2/getrlimit.2.html).  Can also be caused by exceeding the limit
              specified in /proc/sys/fs/nr_open.

The long short here, the error is thrown by whatever libuv is using in their implementation of fs_open, due to the user having too many files open as a general thing.

EMFILE errors are not just limited to the current process but I believe they are also related to the parent process(es?). Either way, I am reasonably confident this error (and #351) are both unrelated to anything directly happening in plenary or even Neovim for that matter. Especially as this is not a consistently reproducible error.

Consider looking into your other system processes to see if you can hunt down what is consuming so many file handles? I am not super great at hunting these down myself.

shawnyu5 commented 2 years ago

Interesting. Fair enough, I'll look around my system processes, see what can be causing this. Thanks for point to the right direction.

demigodliu commented 2 years ago

Is it resolved please?

miversen33 commented 2 years ago

@demigodliu I'm unsure what you're asking for here, as I mentioned above this is almost certainly not a neovim issue. Did you follow the steps I outlined above to troubleshoot?

Can you provide anything useful towards further debugging this if you believe it is a neovim issue?

GordianDziwis commented 3 months ago

I encounter this issue when I have too many paths in the library key in the lua_ls settings.