-
-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PackerUpdate UI freezes in iTerm2 on MacOS #202
Comments
Thanks for the report! Unfortunately, my ability to debug this one is next to nil - I don't have access to a MacOS environment. Did this start recently? In particular, had you updated I'm almost wondering if this is an upstream bug. It sounds like it could be a problem with Neovim's rendering. The |
Not sure if iTerm2 is important here but I run |
This has been going since way back when I first reported the issue about Packer freezing during the Git password prompt. I've been meaning to report it for a while. My current version info:
On my Linux machine, I was not able to reproduce this in Urxvt:
But I was able to reproduce on the Mac in Terminal.app. I have also been having trouble lately with Terminfo not working right on my Mac. So I actually have a suspicion that the problem ultimately lies with whatever is wrong with my Terminfo database, and not iTerm specifically. Which would explain why it fails in all Mac terminals, succeeds in a Mac GUI, and succeeds in all Linux terminals & GUIs. This might be a non-issue and/or an upstream issue. Need to investigate more when I have time. Edit: Terminfo issue turned out to be local to my shell init script. Frozen Packer window issue persists in Terminal.app and iTerm2. |
@gwerbin I'm having the same issue on my mac, please let me know if you find a solution |
@mherna: Also with iTerm2/Terminal.app? @akinsho, what terminal emulator do you use? Have you had this problem with Have you had this/similar problems with other Neovim plugins, e.g. Finally, could you please update |
I use |
Thanks - for reference, I also exclusively use |
I am gonna risk being funny here but a good while ago I though I experienced something like that. It was all due to window being pretty small (in multiple planes) and for some reason packer/nvim was waiting for me to hit enter after showing some message, if I remember correctly it was about rplugin file being created/updated. It could be something like this perhaps? |
Ah - Neovim (or Vim) will prompt for |
During one of these window freezes, I don't see any prompt appear, and I don't see output in Also, the window is not really freezing. I can still interact with Nvim by moving the cursor, typing Ex commands, etc. But the information in the Packer window gets stuck part-way through updating. It happens no matter how big the terminal window is. I still wonder if this is an upstream Nvim issue relating to how control codes are processed by both of these Mac terminals. What mechanism does Packer use to redraw the window? |
Packer uses As far as I know, this is fairly standard? Looking at |
@wbthomason yes, the issue also happens in Here are the logs. It appears to get stuck waiting for
|
@wbthomason if running |
How did you get those logs? I'd like to check mine as well. I think I once had that "no such ref" problem in a plugin, and fixing it resolved the issue for a short while. Maybe there's something going wrong when Packer clones certain plugins from Github, causing it to freeze? |
@gwerbin |
If it helps... I use @tjdevries neovim configuration |
Unfortunately I don't see any such output in my case. I just see the "already clean!" message. Would it help to post my compiled packer script? |
@gwerbin: I recently added more debug logging; if you're not on the latest version of @mherna: That output actually points more toward a problem with It seems that either (as #200 might also imply) the git hanging issue is not as fixed as we thought in #91. I'm wondering if there's something different with the It is also possible that there's an issue in the |
@wbthomason I was pressing the The git version I was running was I also reviewed my environment variables, and I have no variables related to git, which could affect As you say, it is probably related to #200
|
Okay so turn of events but I'm now seeing this issue on my mac as well using |
I just experimented with the solution from #149 i.e. I ran |
I have 130 plugins @wbthomason, @akinsho is correct setting |
I have about 70 on my mac, I'm curious how many jobs packer is running to actually hit this limit in the first place. The things I found on this indicate macOS is a little stingy but still seems like the default is in the thousands so wondering how packer could hit this unless its running like 10-20+ jobs per plugin? EDIT: also wondering what happens to all the jobs if you press |
@akinsho: Right, I too am surprised that Does this ever happen in a fresh terminal, i.e. a shell process with no chance of previously opened files that are lingering, etc.? |
Not sure @wbthomason I use tmux and have windows and panes up for ages but do restart my Mac now and again. Not sure if it'd be different in a new shell can try and see when next I get a chance. |
The file limit does seem to be the issue. I was experiencing this as well and I have 82 plugins. Setting the higher limit with |
@wbthomason I've tried a few times and this seems to eventually creep up, this article is quite a useful explainer but the TLDR is that it's a per application limit i.e. all of nvim's files are included in this not just packer but the limit is still 10,000 +. by default If it helps I've never experienced this issue prior to using packer so I don't think this is some other errant code in some part of nvim. I wonder if some tidying up of resources is required between backer runs like I wonder if the files could be visualised and I could use that to track the count over time |
I also have this problem. The Packer UI freezes vim every time on Sync/Update/Install. Some notes:
Basically the plugin is completely unusable for me because of this mysterious freezing. |
I started to get the same issue too after adding some new plugins. Which took the number to 76 if I go to 73 plugins as @kyoh86 said, it works fine. Once I add an extra plugin I hit this issue.
|
Regarding set Another thing to note is that the UI will sometimes block if there is an error somewhere with a plugin which isn't ideal, but I have seen this before if there are issues with a plugin spec |
@akinsho I didn't add it to any shell startup files. I only ran it inside a shell and tested to see if it will work first or not, before deciding to make it permanent. |
Chiming in to say I just experienced this as well. I dropped some plugins and now the update window seems to work again |
@mhanberg/anyone else: I don't suppose you have the specs that you dropped to make this work? This is a mysterious bug; maybe we can isolate specific features, e.g. that are present in the troublesome specs? Though as @smackesey notes, apparently this (sometimes) happens with only 1 plugin spec, so maybe not. I'm mostly mystified by the inconsistency; plenty of macOS users seem to have no trouble with |
@wbthomason In my case it didn't really matter which specs/plugins I drop. As long as the total number is <= 73 it works. I can constantly replicate the issue with nearly any 73 plugin combination. |
Good to know, thanks. I would expect the |
@ahmedelgabri it might be worth going through the post around ulimit on your own there are some comments in there that helped me debug the limit and the number of process my shell had running https://superuser.com/questions/433746/is-there-a-fix-for-the-too-many-open-files-in-system-error-on-os-x-10-7-1 |
The UI started freezing with more plugins. See wbthomason/packer.nvim#202
Just reviving this issue and reporting a bit of new info-- I updated to macOS Monterey and was hoping maybe this problem would disappear, but nothing has changed. |
For me it seems like |
FWIW I use the the nvim-treesitter plugin which will launch more processes with |
I am having the same problem too. Packer has not been able to update my packages for a good 2 months or so. It just freezes. |
This fixes my issue. Setting max jobs to 4. I am on MacOSX. |
Update: After modifying I am also experiencing a total UI lock and freeze running on macOS
|
just hit this problem on arch linux with neovim 0.6, all mentioned solutions above did not work out |
Add |
How can I fix this, where should I put |
require('packer').startup({
function(use)
-- Packer can manage itself
use {'wbthomason/packer.nvim'}
end,
config = {display = {open_cmd = 'leftabove 75vnew \\[packer\\]'}, max_jobs = 10}
})
|
The default config makes PackerInstall/Sync freeze up unless you set this config value [as recommended in this packer.nvim issue](wbthomason/packer.nvim#202).
PackerUpdate
andPackerSync
cause the Packer window to freeze when running within iTerm 2 on MacOS. It's unclear if the operation behind the UI completed successfully and the UI just crashed/froze, or if the underlying operation also crashed/froze. The only warning/error is a message that redrawtime had been exceeded. I tried setting redrawtime to something really high, like 20000, but I still get the error (and it triggers in less than 20 seconds).When running the same update command in Neovim-Qt on the same machine, it works fine and the Packer window says "Everything up to date", although it takes several seconds to render any text in the Packer window at all. I do not get the redrawtime warning under Neovim-Qt.
The frozen update screen looks something like this:
The text was updated successfully, but these errors were encountered: