Closed Kayzels closed 3 months ago
Please remove lazy.nvim from the repro steps.
Also note I don't have access to Windows, so it is unlikely anyone will fix this.
Please remove lazy.nvim from the repro steps.
Unfortunately it's got to do with the LazyVim integration. Without LazyVim, the error doesn't happen. But it also only happens in LazyVIm if gitsigns is enabled, and the commit is later than cdfcd9d.
Also note I don't have access to Windows, so it is unlikely anyone will fix this.
Yeah, being on Windows is more trouble than its worth. I'm strongly considering moving to Linux, but unfortunately still need Windows for university stuff.
From what I can tell, gitsigns is preventing Neovim from closing because it thinks there's still a git repo open.
I understand not being able to fix it -- I can just keep it pinned to the commit that still works, if there is no obvious way to resolve it.
I am on macOS and have had separate issues (startup backtrace) on anything after cdfcd9d39d23c46ae9a040de2c6a8b8bf868746e
+ LazyVim myself, which I brought up on the Gitter discussion board.
I bring it up here because of the common denominator of the commit, even though we have completely different behaviors. I have opened this discussion item on the LazyVim side because I doubt I have enough info to open a proper issue.
Let's not conflate all backtrace issues into one. From what I can tell they are separate issues.
Hello,
I'm running into this issue as well. It happens if using gitsigns without a manager, and just doing the normal setup song + dance. I noticed that there is always a git.exe instance in the background that just refuses to close.
If there was a way we could force gitsigns to disengage or "close" these git instances during the ExitPre
or VimLeavePre
autocmd, I think that would be an OK workaround on windows. I'd had to uninstall gitsigns, as it's made my life easier when I need to edit projects on Windows.
As it stands now, even :qa!
can block on exit π
@bruxisma would you be able to create a reproducible version that doesn't use LazyVim, then? I have noticed that some tasks don't close when Neovim does, so it's possibly a Neovim issue, not just restricted to Gitsigns. For me, I've noticed I've needed to manually stop the lsp servers under the nvim process from Task Manager. LuaLS especially likes to keep itself open.
For now, you don't need to uninstall Gitsigns, you could just pin it to the commit before it stopped working.
Apparently someone had a similar issue and was resolved by removing a call to setup()
as they were calling it twice. Even though setup()
is allowed to be called multiple times, I can theorize how some of the recent refactorings may introduce the potential for some issues.
If anyone can confirm this, that would be helpful. Otherwise, this still needs to be debugged by someone who can reproduce the issue.
I think I can mostly confirm this. I say mostly, because I did not scour the Lazy source code to find an explicit setup()
call, but I assume there must be one when I enable the plugin.
My issues, which were an intermittent once every other or three startup stacktraces, went away when I made the below material change (removing the setup()
call) to my .config/nvim/plugins/lua
GitSigns additional config Lua.
The normal pattern, mostly, is to duplicate the setup inside a return
, so I was quite baffled for a long time until I saw a post somewhere that prompted me to try using just opts
outside of a setup()
.
1 β diff --git a/.config/nvim/lua/plugins/gitsigns.lua b/.config/nvim/lua/plugins/gitsigns.lua
2 β index 5d46475f..b93b71a2 100644
3 β --- a/.config/nvim/lua/plugins/gitsigns.lua
4 β +++ b/.config/nvim/lua/plugins/gitsigns.lua
5 β @@ -1,8 +1,7 @@
6 β return {
7 β "lewis6991/gitsigns.nvim",
8 β - enabled = true,
9 β - require("gitsigns").setup({
10 β -
11 β + event = "LazyFile",
12 β + opts = {
13 β signs = {
14 β -- Colors may be changed via the according highlight groupd, check :h gitsigns-highlight-groups
15 β add = { text = "+" },
16 β @@ -50,5 +49,5 @@ return {
17 β row = 0,
18 β col = 1,
19 β },
20 β - }),
21 β + },
22 β }
Thank you @sinkr . This gives me a good idea where to look for issues.
@bruxisma would you be able to create a reproducible version that doesn't use LazyVim, then? I have noticed that some tasks don't close when Neovim does, so it's possibly a Neovim issue, not just restricted to Gitsigns. For me, I've noticed I've needed to manually stop the lsp servers under the nvim process from Task Manager. LuaLS especially likes to keep itself open.
For now, you don't need to uninstall Gitsigns, you could just pin it to the commit before it stopped working.
@Kayzels So I actually don't use LazyVim at all. I use lazy.nvim as a package manager. When I was writing my comment earlier, I actually thought LazyVim was a typo that you had used to refer to lazy.nvim (I wrote my issue at 3:30 AM my time as I was pulling a late night and was tired of running into this issue)
That said, the lazy.nvim configuration I use for gitsigns is
{
"lewis6991/gitsigns.nvim",
event = "VeryLazy",
opts = {
signs = {
changedelete = { text = "ο" },
delete = { text = "ο" },
change = { text = "ο" },
add = { text = "ο" },
},
},
},
Hopefully this can add some additional information to what @sinkr showed above.
No not really. Need to be able to reproduce this without lazy, otherwise I consider this a lazy issue.
I swear VeryLazy causes more problems than it solves (none).
As I stated in my initial comment, I was able to replicate this happening without using lazy.nvim (or VeryLazy as an event loader). I had manually cloned, manually loaded, and manually called setup() and was still having the issue.
When VeryLazy is removed, a background git.exe instance is always executing. When it is present it only happens if I'm editing in a git repository (which isn't always. sometimes I have scratch files I work on).
That said, as I'm writing this comment, I do wonder if maybe the core.fsmonitor
git config setting has anything to do with it, as this was causing issues for me under a separate tool (and the fix there was to force git to execute with the fsmonitor config value forced to false). I'll try to disable the fsmonitor and see if it's the cause and report back in a little while (unfortunately, I have IRL meetings)
Ok, after spending some time testing, core.fsmonitor
does not affect whether the nvim halts on exit. However if core.fsmonitor
is disabled, it freezes as it goes to "save" the current buffer. With core.fsmonitor
enabled it freezes as soon as :wqa
is entered.
With that said, I was able to narrow down some of the behavior. This only appears (for me) to happen in files/buffers where:
add
sign are present. (change
and changedelete
do not seem to have any affect)I'm unable to get either case to reliably happen separate from each other.
Thank you @bruxisma for the detailed troubleshooting here. This makes a lot more sense and I can confirm I'm having similar problems. I've pinned to cdfcd9d and can confirm this does not have the freezing issues.
I know its been stated numerous times in this issue to remove all lazy/LazyVim references to isolate the variables, but just adding my troubleshooting steps when I initially ran into this problem (had no idea it was possibly related to gitsigns):
add
s (among other changes)add
s and other changes):q
(final close would freeze)lazy.nvim
gitsigns
just so happened to be the second-to-last one I enabled, freezing was backgitsigns
and could reproduce the issueAgain, I know this is not a sufficient troubleshooting as already discussed in this issue, but at least maybe this can help other people stepping through similar logic to find some common themes and they can help us gather more information. Unfortunately I'm not home today to work on this so I can't offer much in the way of finding a fix.
After several hours of not being able to pinpoint the problem I disabled every plugin manually through lazy.nvim
- Stepped through enabling every single plugin 1-by-1, issue was not happening
- gitsigns just so happened to be the second-to-last one I enabled, freezing was back
- Disabled everything else, enabled gitsigns and could reproduce the issue
Is there anything preventing you from producing a testcase (as per the issue template)? Otherwise, this information is much less helpful than you think. Without being able to properly debug this, anything can be happening.
I'll copy the steps here for convenience.
Here is the template for a minimal init.lua:
for name, url in pairs{
gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
-- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
} do
local install_path = vim.fn.fnamemodify('gitsigns_issue/'..name, ':p')
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system { 'git', 'clone', '--depth=1', url, install_path }
end
vim.opt.runtimepath:append(install_path)
end
require('gitsigns').setup{
debug_mode = true, -- You must add this to enable debug messages
-- ADD GITSIGNS CONFIG THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUE
}
-- ADD INIT.LUA SETTINGS THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUE
This init.lua can be used by running git --clean -u init.lua
.
Provide this along side instructions like:
mkdir issue_dir
cd issue_dir
git init
nvim --clean -u init.lua
.If this is provided and I am able to reproduce this, then I can debug it and fix it.
@lewis6991 sure I will work on this today, I'm a bit limited on what I can test at work but I should be able to reproduce the issues here.
@lewis6991 as requested
Content of repro config init.lua
:
for name, url in pairs({
gitsigns = "https://github.com/lewis6991/gitsigns.nvim",
}) do
local install_path = vim.fn.fnamemodify("gitsigns_issue/" .. name, ":p")
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
end
vim.opt.runtimepath:append(install_path)
end
require("gitsigns").setup({
debug_mode = true, -- You must add this to enable debug messages
})
Steps to reproduce:
mkdir issue
cd issue
init.lua
git init
foo.txt
("hello" works fine)git add foo.txt
git commit -m foo
foo.txt
, add a new line and then some text, write and close (do not commit)mkdir dummy
cd dummy
foo.txt
with a line of text and commit, then add some more text on a new line and do not commit)cd ..
nvim --clean -u init.lua
:e foo.txt
:tabnew
:tcd dummy
:e foo.txt
:q
(closes the tab in dummy
):q
(this should cause a freeze)The above steps could maybe be combined to be a bit less verbose but wanted to be explicit about separate commands.
NOTE: I was not able to reproduce the issue on WSL with the above steps.
Thanks.
I was hoping that since you can reproduce this in WSL that I could repro it on Mac, but I couldn't.
Looks like I need to build a VM to try and repro this.
EDIT: Looks like WSL doesn't work in MacOS VM's as it doesn't support nested virtualisation.
I was hoping that since you can reproduce this in WSL that I could repro it on Mac, but I couldn't.
Just to clarify I can not repro in WSL :)
I'm happy to try and take a stab at it when I get home, I have a Windows machine I can work on. Running the above steps, I was not able to find any debug/log file for gitsigns -- is there something else I need to enable in the options to output it?
The logs are all internal to the session. You can see them by running :Gitsigns debug_messages
. That will log each system command as it is spawned.
Just to clarify I can not repro in WSL :)
Ah sorry, I misread. This must indeed be a window issue.
Also the :tcd
gives one clue as this calls the DirChanged
autocmd which is setup here. This will then call update_cwd_head_debounced()
which is also called during setup()
.
Something about that function is causing issues and might also explain why some users are getting similar problems when calling setup twice is it will invoke update_cwd_head_debounced()
again.
As maybe an exercise in futility, I edited the cprint
log function to write to an output file with millisecond second timestamps. I wanted to see if I could capture anything useful when the freeze occurs since I can't run commands at that point, and wanted to have a sense of time when reading.
+local log_file = vim.uv.cwd() .. '/gitsigns.log'
-- If called in a callback then make sure the callback defines a __FUNC__
-- variable which can be used to identify the name of the function.
--- @param obj any
--- @param lvl integer
local function cprint(obj, lvl)
...
table.insert(M.messages, msg2)
+ local f = assert(io.open(log_file, 'ab'))
+ local sec = vim.uv.gettimeofday() -- I'm dumb, these are seconds
+ f:write(sec .. ' ' .. msg2)
+ f:write('\n')
+ f:flush()
+ f:close()
end
I don't see much here but maybe you'll see something useful.
The only thing I found remotely interesting is that the cwd_watcher_cb
fires at essentially the same time as detach
(1717618371
and 1717618372
), presumably when :q
is ran on the last buffer. No idea if this is expected behavior so don't want to speculate too much.
EDIT: never mind I'm an idiot, those were seconds not ms... π€¦
Running on debug mode gives
Assertion failed: req != current, file C:\Users\gocdu\programs\neovim\.deps\build\src\libuv\src\win\req-inl.h, line 99
which is referencing this line.
Easier reproduction steps:
Run nvim --clean -u init.lua
where init.lua
is
for name, url in pairs({
gitsigns = "https://github.com/lewis6991/gitsigns.nvim",
}) do
local install_path = vim.fn.fnamemodify("gitsigns_issue/" .. name, ":p")
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
end
vim.opt.runtimepath:append(install_path)
end
require("gitsigns").setup({
debug_mode = true, -- You must add this to enable debug messages
})
vim.cmd[[tabnew]]
vim.cmd[[tcd ..]]
Creating git repos, commiting files and the other stuff is not necessary, just run the above anywhere and quit neovim.
Minimaler repro:
Run nvim --clean -u freeze.lua
where freeze.lua
is
local watcher = assert(vim.uv.new_fs_event())
watcher:start('.', {}, function()
print('hello')
end)
watcher:stop()
watcher:start('.', {}, function()
print('bye')
end)
Can people try #1031
Description
This happens specifically with a LazyVim setup, but they cannot reproduce it, so checking if there might be more luck here.
Using Neotree, you can change the current working directory by pressing
.
. Doing this in a git repo, or changing to git repo using it, causes Neovim to freeze on exit. Importantly, it only seems to happen if the Neovim is started in a folder that is a git repo.Maybe its having an issue with the cwd update? The maintainers of the LazyVim repo couldn't reproduce, so possibly its Windows specific? I noticed that the last working commit that didn't cause this was cdfcd9d - it broke from 720061a.
Any non-git folders aren't affected, and using an older version of gitsigns doesn't cause the issue.
Unfortunately, because it's happening with LazyVim, the repro needs to include that, so it's not particularly small any more.
Neovim version
NVIM v0.10.0 Release
Operating system and version
Windows 10 Pro 22H2 19045.3803
Expected behavior
Neovim should exit without freezing the terminal.
Actual behavior
Neovim hangs on exit.
https://github.com/lewis6991/gitsigns.nvim/assets/72696811/6c699395-d1bb-410e-8c77-546a8e850bc8
Minimal config
Steps to reproduce
repro.lua
(or `minimal.lua, but then you need to update the nvim command.git init
nvim --clean -u repro.lua
repro.lua
file from Neotree, navigating to it by typing:Neotree
.Backspace
to go up a folder.repro.lua
file.Backspace
to see a list of the directories including the created one containing therepro.lua
file..
on the folder that contains therepro.lua
file.repro.lua
file.:qa
.Gitsigns debug messages