Assertion failed in coroutine #847

scallaway · 2023-07-27T10:22:40Z

Description

This is very similar to #814, but happening in a slightly different part of hunks.lua.

I can't work out quite when this crash happens, but I've found it to happen pretty consistently in a Python file that is open for a minute or so. Of course when the error shows, the git signs completely vanish.

I had a run through the hunks.lua file and found the assert thats failing. I commented it out and had a play around with the minimum config again and that seems to do the job, but I can't be sure that's not absolutely required in the plugin.

Neovim version

nightly

Operating system and version

debian

Expected behavior

No response

Actual behavior

Error output is the following;

Error executing vim.schedule lua callback: ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:76: The coroutine failed with this message: ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: assertion failed!
stack traceback:
        [C]: in function 'assert'
        ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: in function 'calc_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:59: in function 'apply_win_signs0'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:81: in function 'apply_win_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:454: in function 'fn'
        ...tform/gitsigns_issue/gitsigns//lua/gitsigns/debounce.lua:76: in function 'update'
        ...gitsigns_issue/gitsigns//lua/gitsigns/watcher.lua:88: in function <...gitsigns_issue/gitsigns//lua/gitsigns/watcher.lua:59>
stack traceback:
        [C]: in function 'error'
        ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:76: in function 'cb'
        ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:113: in function 'cb'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:36: in function <...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:34>

Minimal config

for name, url in pairs({
	gitsigns = "https://github.com/lewis6991/gitsigns.nvim",
	-- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
	nvim_lspconfig = "https://github.com/neovim/nvim-lspconfig",
}) 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

require("lspconfig").pyright.setup({})

Steps to reproduce

nvim --clean -u minimal.lua
Wait for a little bit

Gitsigns debug messages

No response

The text was updated successfully, but these errors were encountered:

lewis6991 · 2023-07-27T13:04:44Z

I improved the assertion message in 61e50f3. Can you report the message when it happens again.

scallaway · 2023-07-27T13:12:28Z

Error executing vim.schedule lua callback: ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:76: The coroutine failed with this message: ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: Invalid hunk with untracked=true hunk="@@ -2308,1 +2308,3 @@"

stack traceback:
        [C]: in function 'assert'
        ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: in function 'calc_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:59: in function 'apply_win_signs0'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:81: in function 'apply_win_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:454: in function 'fn'
        ...tform/gitsigns_issue/gitsigns//lua/gitsigns/debounce.lua:76: in function 'update'
        ...gitsigns_issue/gitsigns//lua/gitsigns/watcher.lua:88: in function <...gitsigns_issue/gitsigns//lua/gitsigns/watcher.lua:59>
stack traceback:
        [C]: in function 'error'
        ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:76: in function 'cb'
        ...gitsigns_issue/gitsigns//lua/gitsigns/async.lua:113: in function 'cb'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:36: in function <...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:34>
Error in decoration provider gitsigns.win:
Error executing lua: ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: Invalid hunk with untracked=true hunk="@@ -2308,1 +2308,3 @@"
stack traceback:
        [C]: in function 'assert'
        ...gitsigns_issue/gitsigns//lua/gitsigns/hunks.lua:172: in function 'calc_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:63: in function 'apply_win_signs0'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:81: in function 'apply_win_signs'
        ...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:511: in function <...gitsigns_issue/gitsigns//lua/gitsigns/manager.lua:502>

That's what I get on the latest version of gitsigns

scallaway · 2023-07-27T13:21:10Z

For what it's worth, that's editing the same file that I was recreating the issue on earlier. It's a file that already exists in source control and I've just updated some lines (edited a few, added a few).

The line 2308 that it's outputting there is a line that I've edited.

lewis6991 · 2023-07-27T14:46:53Z

Gitsigns doesn't think this file is maintained in git for whatever reason (due to untracked=true).

This will come from when Gitsigns run git ls-files <filename> and then determines whether the file is tracked based on the result. You would have seen this in the debug messages, however this hasn't been provided in the issue report.

scallaway · 2023-07-27T15:28:37Z

Gitsigns doesn't think this file is maintained in git for whatever reason

Hmm that's strange, do you believe it's not an issue with gitsigns then?

You would have seen this in the debug messages, however this hasn't been provided in the issue report.

So I can see that git ls-files is being called, but I can't see in :Gitsigns debug_messages whether there is a problem with the output or not.

Also, just realised that I didn't include this in the first issue, but I can recreate this very easily when I have to separate files open in two panes (split vertically but I haven't tried any other way).

lewis6991 · 2023-07-27T15:38:31Z

It could be, but it's hard to tell. There could be a race condition.

Without a reliable way to repro this, I'm not sure what to suggest.

alligatortower · 2023-08-02T17:42:56Z

From casual observation this error seems to happen to me when switching out of (or perhaps back to) the tmux tab where I'm running neovim. If it's the result of something I'm doing while tabbed away, I haven't noticed a pattern. It's extremely intermittent in all cases.

mosheavni · 2023-09-03T15:30:39Z

happens to me frequently as well

astutecat · 2023-09-04T07:05:08Z

I tend to see this issue happen when I do some git-related calls outside of nvim in another tmux window - for example reverting changes or some other index-based operations.

If you use stacked git, it appears to happen a lot if you use it to insert changes into another commit -- this operation presumably involves rapidly stashing/reverting and re-applying of changes.

scallaway · 2023-09-04T08:01:27Z

I tend to see this issue happen when I do some git-related calls outside of nvim in another tmux window

This is interesting.

I do use Lazygit in another tmux window, so that might be affecting it.

I'm going to run a temporary branch (https://github.com/scallaway/gitsigns.nvim/tree/temp-fix-assertion) for a while to see if anything else badly breaks. Given as far as I can tell that's the line that is complaining the entire time.

astutecat · 2023-09-04T08:15:30Z

using lazygit and doing reverts, stashes ... something like that where the index changes seems to trigger it. Some kind of 'rug-pull' where the file goes from being in a modified state to not?

lewis6991 · 2023-09-04T13:48:02Z

I just want to point out no one has yet to provide the output of debug messages when this error occurs. The debug messages should indicate what commands for each buffer is being issued as well as whenever the gitdir watcher triggers.

lewis6991 · 2023-09-04T14:03:55Z

I don't know if this will fix the issue but #869 should fix some related problems around certain kinds of 'rug-pulls'.

I would appreciate if anyone facing this issue could test this and report back.

scallaway · 2023-09-05T10:45:39Z

I just want to point out no one has yet to provide the output of debug messages when this error occurs.

I've just pulled the following logs out now that I've been able to see it happen a few times. Note that file names are redacted.

-- Console error --
Error executing vim.schedule lua callback: ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:76: The coroutine failed with this message: ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/hunks.lua:172: Invalid hunk with untracked=true hunk="@@ -16,1 +16,1 @@"
stack traceback:
        [C]: in function 'assert'
        ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/hunks.lua:172: in function 'calc_signs'
        ...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:50: in function 'apply_win_signs0'
        ...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:72: in function 'apply_win_signs'
        ...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:445: in function 'fn'
        ...ack/packer/start/gitsigns.nvim/lua/gitsigns/debounce.lua:76: in function 'update'
        ...pack/packer/start/gitsigns.nvim/lua/gitsigns/watcher.lua:103: in function <...pack/packer/start/gitsigns.nvim/lua/gitsigns/watcher.lua:77>
stack traceback:
        [C]: in function 'error'
        ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:76: in function 'cb'
        ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:113: in function 'cb'
        ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:186: in function <...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:184>
Press ENTER or type command to continue

-- Debug messages --

cli.run: Running action 'debug_messages' with arguments {}
watcher_cb(1): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(72): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(74): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(93): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(96): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(30): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(198): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(44): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(201): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(217): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(255): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(1): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(72): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(74): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(93): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(96): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(198): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(44): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(201): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(217): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(255): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(1): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(72): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(74): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(93): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(96): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(30): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(198): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(44): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(201): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(217): Git dir update: 'FETCH_HEAD' { change = true }
watcher_cb(255): Git dir update: 'FETCH_HEAD' { change = true }
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol working_dir/*.py

run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.ts
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.tsx
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir working_dir.git show :0:*.py
update(1): updates: 3746, jobs: 5644
update(72): updates: 3747, jobs: 5644
update(74): updates: 3748, jobs: 5644
update(93): updates: 3749, jobs: 5644
update(96): updates: 3750, jobs: 5644
update(198): updates: 3751, jobs: 5644
update(44): updates: 3752, jobs: 5644
update(201): updates: 3753, jobs: 5644
update(217): updates: 3754, jobs: 5644
update(255): updates: 3755, jobs: 5644
cli.run: Running action 'dump_cache' with arguments {}
cli.run: Running action 'debug_messages' with arguments {}

For context, this only seems to happen in the pane that contains a Python file. I had two vertical panes setup, one with a JSX file and one with a Python file. I can't remember which one was focused (as I was tabbed out).

lewis6991 · 2023-09-05T11:00:01Z

Redacting all filenames to * makes it difficult to see what jobs are running on each file. I can only assume that every file in this log is getting:

watcher_cb(buf) ...
watcher_cb(buf) ...
watcher_cb(buf) ...
git rev-parse ... HEAD
git ls-files ... <file>
git show :0:<file>

My only guess is that the information of rev-parse is stale by the time git show is run.

lewis6991 · 2023-09-05T12:37:50Z

I've updated #869 with some changes to how the watcher is debounced.

If anyone sees this issue with this PR applied, then please report the debug messages.

Please refrain from any further "me too!" comments.

scallaway · 2023-09-05T12:46:50Z

👍

I'll run that PR from right now

lewis6991 · 2023-09-22T11:38:23Z

Any issues yet?

scallaway · 2023-09-29T16:04:48Z

I keep meaning to come back to this - I just haven't had time this week.

I am still seeing issues (and can see you merged the PR into the base branch) but I want to try and find another good recreation to get you the info that you require

scallaway · 2023-10-05T10:47:58Z

Does this help?

update(28): updates: 1686, jobs: 79
update(1): updates: 1687, jobs: 79
update(322): updates: 1688, jobs: 79
update(323): updates: 1689, jobs: 79
update(324): updates: 1690, jobs: 79
watcher_cb(1): Git dir update: '.gitstatus.KLajmI' { rename = true }
watcher_cb(28): Git dir update: '.gitstatus.KLajmI' { rename = true }
watcher_cb(322): Git dir update: '.gitstatus.KLajmI' { rename = true }
watcher_cb(323): Git dir update: '.gitstatus.KLajmI' { rename = true }
watcher_cb(324): Git dir update: '.gitstatus.KLajmI' { rename = true }
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol /home/s
callaway/dev/work/work_repo/dir_a/tests/test.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol /home/s
callaway/dev/work/work_repo/dir_a/store.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol /home/s
callaway/dev/work/work_repo/dir_b/trigger/store.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol /home/s
callaway/dev/work/work_repo/dir_b/tests/strategies.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git diff --name-status -C --cached
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git -c core.quotepath=off ls-files --stage --others --exclude-standard --eol /home/s
callaway/dev/work/work_repo/dir_a/user_model.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git diff --name-status -C --cached
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git show :0:dir_a/store.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git show :0:dir_a/tests/test_actions.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git show :0:dir_b/trigger/tests/strategies.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git show :0:dir_b/trigger/store.py
run_job: git --no-pager --literal-pathspecs -c gc.auto=0 --git-dir /home/scallaway/dev/work/work_repo/.git show :0:dir_a/user_model.py
update(1): updates: 1691, jobs: 96
update(322): updates: 1692, jobs: 96
update(28): updates: 1693, jobs: 96
update(323): updates: 1694, jobs: 96
update(324): updates: 1695, jobs: 96
cli.run: Running action 'debug_messages' with arguments {}

lewis6991 · 2023-10-05T11:18:13Z

What was the error?

astutecat · 2023-10-09T07:56:01Z

Heya, I just wanted to say that I haven't seen this error recently and the hunks status in nvim seems to update more seamlessly when I do things in lazygit. So for me, it seems to be a lot better.

scallaway · 2023-10-13T10:12:34Z

@lewis6991

What was the error?

Managed to capture it just as it happened, this is what I see

Although this still isn't truly reproducable. Takes ages to find the error as I'm not always working with Python either. Fwiw, this happened in TSX/JSX files only:

Error executing vim.schedule lua callback: ...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:76: The coroutine failed with this message: ...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/hunks.lua:172: Invalid hunk 
with untracked=true hunk="@@ -3,1 +3,4 @@"                                                                                                                                                                                       
stack traceback:                                                                                                                                                                                                                 
        [C]: in function 'assert'                                                                                                                                                                                                
        ...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/hunks.lua:172: in function 'calc_signs'                                                                                                                                
        ...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/manager.lua:49: in function 'apply_win_signs0'                                                                                                                           
        ...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/manager.lua:72: in function 'apply_win_signs'                                                                                                                            
        ...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/manager.lua:502: in function 'fn'                                                                                                                                        
        .../share/nvim/lazy/gitsigns.nvim/lua/gitsigns/debounce.lua:68: in function 'update'                                                                                                                                     
        ...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/watcher.lua:92: in function <...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/watcher.lua:65>                                                                             
stack traceback:                                                                                                                                                                                                                 
        [C]: in function 'error'                                                                                                                                                                                                 
        ...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:76: in function 'cb'                                                                                                                                         
        ...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:113: in function 'cb'                                                                                                                                        
        ...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/manager.lua:448: in function <...l/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/manager.lua:433>

Edit:

Realised that the first copy/paste was trash and found another one so replaced it

lewis6991 · 2024-04-04T09:27:21Z

Is this still an issue? I am yet to encounter this.

emmanueltouzery · 2024-04-24T14:51:37Z

Since I'm reproducing this from time to time, I could add a print() before the assert with a if inverting the assert condition, and I could print anything. I currently added one printing the whole hunk, not just the first line. If there's something that I could print out that could help you, let me know.

lewis6991 · 2024-04-24T14:54:00Z

So the gitsigns code in the stack trace should only be triggered by a uv.new_fs_event callback. And for some reason, diffview is included in the trace. I have no idea why this could happen.

emmanueltouzery · 2024-04-25T13:46:52Z

I got it again. because previously I was afraid that I may have pasted two stacks from two different errors that would have happened in succession, I'll now paste the screenshot of exactly what's appearing on screen

and this is now with 035da03

this was also from diffview, but this time no diffview in the stack.

lewis6991 · 2024-04-25T13:49:52Z

Ok that looks more normal. And is probably some race condition. The .git watcher is debounced but for some reason that's not avoiding this problem.

Maybe the debounce isn't long enough?

emmanueltouzery · 2024-04-25T13:52:34Z

Right now my computer was under a bit of load. diffview can also sometimes get really quite slow. I think something is keeping the neovim event loop busy, not sure what. Maybe communication with the LSP. So yes, it could be something like that. I'll search for the constant and try increasing it.

Fixes #847

lewis6991 · 2024-04-25T15:04:14Z

@emmanueltouzery can you try #1008 . Hopefully that should fix it.

emmanueltouzery · 2024-04-25T15:16:00Z

great! I updated to that version and i'll report if i still get the error! 🤞

emmanueltouzery · 2024-04-26T08:11:36Z

FYI, I'm definitely seeing some pathological performance issues on my system right now.

> git --no-pager -c color.ui=always --no-optional-locks rev-parse --short 2769bf5cd5699bc803c4899e0e1e0b32adbae599
Command "git --no-pager -c color.ui=always --no-optional-locks rev-parse --short 2769bf5cd5699bc803c4899e0e1e0b32adbae599" running for more than: 4.9 seconds

let's say my system absolutely exacerbates what is otherwise a real issue. maybe i should run some git gc or something.

EDIT:

git --no-pager -c color.ui=always --no-optional-locks describe --long --tags HEAD
Command "git --no-pager -c color.ui=always --no-optional-locks describe --long --tags HEAD" running for more than: 2.6 seconds

to be clear, these operations run instantly otherwise. presumably git lock contention due to too many concurrent git invocations from one or the other neovim plugin.

lewis6991 · 2024-04-26T09:04:32Z

There could definitely be contention, especially if you have lots of buffers open. I've added --no-optional-locks to #1008 just in case it helps things.

I believe to avoid the bug, Gitsigns needs to be able to run these two commands without any interference from other plugins or processes:

# This tells us the object name of the tracked version of `<path>`. We use this to determine whether the file is tracked or not.
git ... ls-files --stage --others --exclude-standard --eol <path>
# This gets us the contents of tracked version of <path> in the index.
git ... --git-dir <gitdir> show :0:<path>

If anything interferes with that, then that error can appear, since the information from each command won't be in sync.

emmanueltouzery · 2024-04-26T10:17:22Z

i think the no-optional-locks help. it feels less sluggish. but it's had to judge. i'll report if i see the assertion again.

Fixes #847

emmanueltouzery · 2024-04-27T18:02:52Z

maybe only interesting for me, but... i now wonder whether i got myself in trouble with git performance due to diffview leaving hidden buffers behind sindrets/diffview.nvim#477

I can't be sure, i'll pay attention in the future. But I do run diffview a lot. It's possible it left behind a bunch of unlisted buffers and that gitsigns attached to them and that that got me in trouble. And I didn't think of checking for unlisted buffers previously. I'll pay attention in the future.

EDIT: aha, but unlisted buffers are unloaded/deleted.. presumably gitsigns wouldn't attach to them 🤔

lewis6991 · 2024-04-27T21:12:23Z

The only way to know would be to look at the Gitsigns cache.

Fixes #847

- diffview, 0.10 deprecations - gitsigns, lewis6991/gitsigns.nvim#847 - devdocs, luckasRanarison/nvim-devdocs#60

scallaway added the bug Something isn't working label Jul 27, 2023

lewis6991 added the needs response label Oct 2, 2023

github-actions bot removed the needs response label Oct 5, 2023

This comment has been minimized.

Sign in to view

teto mentioned this issue Nov 7, 2023

enable luarocks test #913

Open

lewis6991 added the unable to reproduce Unable to reproduce problem label Apr 4, 2024

lewis6991 reopened this Apr 24, 2024

Repository owner deleted a comment from xiantang Apr 24, 2024

lewis6991 added a commit that referenced this issue Apr 25, 2024

fix(update): always update file info when refreshing compare text

da36852

Fixes #847

lewis6991 mentioned this issue Apr 25, 2024

fix(update): always update file info when refreshing compare text #1008

Merged

lewis6991 added a commit that referenced this issue Apr 26, 2024

fix(update): always get object contents from object names

01df36a

Fixes #847

lewis6991 added a commit that referenced this issue Apr 26, 2024

fix(update): always get object contents from object names

c65ffae

Fixes #847

lewis6991 added a commit that referenced this issue May 1, 2024

fix(update): always get object contents from object names

bd55473

Fixes #847

lewis6991 added a commit that referenced this issue May 1, 2024

fix(update): always get object contents from object names

edac9ef

Fixes #847

lewis6991 added a commit that referenced this issue May 1, 2024

fix(update): always get object contents from object names

cd87ad6

Fixes #847

lewis6991 added a commit that referenced this issue May 1, 2024

fix(update): always get object contents from object names

968ec9b

Fixes #847

lewis6991 added a commit that referenced this issue May 1, 2024

fix(update): always get object contents from object names

bc6d995

Fixes #847

lewis6991 added a commit that referenced this issue May 7, 2024

fix(update): always get object contents from object names

a77d5cd

Fixes #847

lewis6991 added a commit that referenced this issue May 22, 2024

fix(update): always get object contents from object names

2c0b671

Fixes #847

lewis6991 added a commit that referenced this issue May 22, 2024

fix(update): always get object contents from object names

196f0c2

Fixes #847

lewis6991 closed this as completed in #1008 May 22, 2024

lewis6991 added a commit that referenced this issue May 22, 2024

fix(update): always get object contents from object names

a28bb1d

Fixes #847

github-actions bot mentioned this issue May 22, 2024

chore(main): release 0.9.0 #1011

Open

emmanueltouzery added a commit to emmanueltouzery/nvim_config that referenced this issue May 22, 2024

plugin upgrades

a5e554d

- diffview, 0.10 deprecations - gitsigns, lewis6991/gitsigns.nvim#847 - devdocs, luckasRanarison/nvim-devdocs#60

Assertion failed in coroutine #847

Assertion failed in coroutine #847

Comments

scallaway commented Jul 27, 2023 • edited

Description

Neovim version

Operating system and version

Expected behavior

Actual behavior

Minimal config

Steps to reproduce

Gitsigns debug messages

lewis6991 commented Jul 27, 2023

scallaway commented Jul 27, 2023 • edited

scallaway commented Jul 27, 2023

lewis6991 commented Jul 27, 2023 • edited

scallaway commented Jul 27, 2023

lewis6991 commented Jul 27, 2023

alligatortower commented Aug 2, 2023

mosheavni commented Sep 3, 2023

astutecat commented Sep 4, 2023

scallaway commented Sep 4, 2023

astutecat commented Sep 4, 2023

lewis6991 commented Sep 4, 2023 • edited

lewis6991 commented Sep 4, 2023 • edited

scallaway commented Sep 5, 2023

lewis6991 commented Sep 5, 2023 • edited

lewis6991 commented Sep 5, 2023

scallaway commented Sep 5, 2023

lewis6991 commented Sep 22, 2023

scallaway commented Sep 29, 2023

scallaway commented Oct 5, 2023

lewis6991 commented Oct 5, 2023

astutecat commented Oct 9, 2023

scallaway commented Oct 13, 2023 • edited

This comment has been minimized.

lewis6991 commented Apr 4, 2024

emmanueltouzery commented Apr 24, 2024

lewis6991 commented Apr 24, 2024

emmanueltouzery commented Apr 25, 2024 • edited

lewis6991 commented Apr 25, 2024 • edited

emmanueltouzery commented Apr 25, 2024

lewis6991 commented Apr 25, 2024

emmanueltouzery commented Apr 25, 2024

emmanueltouzery commented Apr 26, 2024 • edited

lewis6991 commented Apr 26, 2024 • edited

emmanueltouzery commented Apr 26, 2024

emmanueltouzery commented Apr 27, 2024 • edited

lewis6991 commented Apr 27, 2024

scallaway commented Jul 27, 2023 •

edited

scallaway commented Jul 27, 2023 •

edited

lewis6991 commented Jul 27, 2023 •

edited

lewis6991 commented Sep 4, 2023 •

edited

lewis6991 commented Sep 4, 2023 •

edited

lewis6991 commented Sep 5, 2023 •

edited

scallaway commented Oct 13, 2023 •

edited

emmanueltouzery commented Apr 25, 2024 •

edited

lewis6991 commented Apr 25, 2024 •

edited

emmanueltouzery commented Apr 26, 2024 •

edited

lewis6991 commented Apr 26, 2024 •

edited

emmanueltouzery commented Apr 27, 2024 •

edited