`Assertion failed` in `do_clean`
Closed this issue · 19 comments
nvim --version:
NVIM v0.11.0-dev-3643+g0cdeb06db-Homebrew
Build type: Release
LuaJIT 2.1.1720049189
git --version:
git version 2.45.2
- Operating system/version:
macOS Sonoma 14.5
- Terminal name/version:
wezterm 20240715-080945-c9116830
Steps to reproduce
- Save content of
Plugin specification file(s)tosome.lua nvim -nu some.lua:Pckr sync
Actual behaviour
Could't find setting/plugin combo that causes it, seems to be happening even on pretty simple plugin list. Bisecting lead to:
e200b7724ecb0e9c07a32e505592f990266fc819 is the first bad commit.
Error executing Lua callback: ...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:29: The coroutine failed with this message: ...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:108: assertion failed!
stack traceback:
[C]: in function 'assert'
...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:108: in function 'do_clean'
...ne/.local/share/nvim/pckr/pckr.nvim/lua/pckr/actions.lua:332: in function 'sync'
...ne/.local/share/nvim/pckr/pckr.nvim/lua/pckr/actions.lua:396: in function <...ne/.local/share/nvim/pckr/pckr.nvim/lua/pckr/actions.lua:395>
stack traceback:
[C]: in function 'error'
...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:29: in function 'step'
...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:52: in function 'run'
...oune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:110: in function 'cmd_func'
.../gegoune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/cli.lua:89: in function <.../gegoune/.local/share/nvim/pckr/pckr.nvim/lua/pckr/cli.lua:74>
Expected behaviour
No error, do the sync.
pckr files
Plugin specification file(s)
local function bootstrap_pckr()
local pckr_path = vim.fn.stdpath('data') .. '/pckr/pckr.nvim'
if not vim.uv.fs_stat(pckr_path) then
vim.fn.system({
'git',
'clone',
'--filter=blob:none',
'https://github.com/lewis6991/pckr.nvim',
pckr_path,
})
end
vim.opt.rtp:prepend(pckr_path)
end
bootstrap_pckr()
require('pckr').setup({})
require('pckr').add({ 'tpope/vim-repeat' })
I have the same error when trying to install any plugin.
My environment:
- nvim:
NVIM v0.9.5 Build type: RelWithDebInfo LuaJIT 2.1.1707061634 - git:
git version 2.46.0 - OS:
Fedora Linux 39 - Terminal:
QTerminal 1.3.0
Steps to reproduce:
-
Follow Quickstart.
-
Try to add any plugin. What I've tried:
pckr.lua
local function bootstrap_pckr() local pckr_path = vim.fn.stdpath("data") .. "/pckr/pckr.nvim" if not (vim.uv or vim.loop).fs_stat(pckr_path) then vim.fn.system({ 'git', 'clone', "--filter=blob:none", 'https://github.com/lewis6991/pckr.nvim', pckr_path }) end vim.opt.rtp:prepend(pckr_path) end bootstrap_pckr() require('pckr').add{ -- My plugins here -- 'foo1/bar1.nvim'; -- 'foo2/bar2.nvim'; 'mbbill/undotree'; { 'nvim-treesitter/nvim-treesitter', run = ':TSUpdate' }, }
Error and stack traceback
Error detected while processing /home/user/.config/nvim/init.lua:
E5113: Error while calling lua chunk: ...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.
lua:108: assertion failed!
stack traceback:
[C]: in function 'assert'
...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:108: in function 'install'
/home/user/.local/share/nvim/pckr/pckr.nvim/lua/pckr.lua:52: in function 'add'
/home/user/.config/nvim/lua/default/pckr.lua:19: in main chunk
[C]: in function 'require'
/home/user/.config/nvim/lua/default/init.lua:1: in main chunk
[C]: in function 'require'
/home/user/.config/nvim/init.lua:1: in main chunk
Edit:
Issue persists with neovim 0.10.2
I have noticed that I am no longer getting this assertion, instead pckr (sync) works on first invocation after starting nvim only. Consequent runs result in only pckr.nvim being updated (with all other plugins not listed at all).
I am not sure if that's anyhow related to original issue, so please close it if you believe those are unrelated.
I just migrated my configuration from packer to pckr within the past hour or two, and received this error among several others. This error, concerns me the most out of the batch, as it is correlated with the internals of pckr itself, and not external packages.
I've never once had this issue or any similar issue. I'm not sure how to go about debugging this.
I've never once had this issue or any similar issue. I'm not sure how to go about debugging this.
I am running Kali Linux Rolling Release, for which Neovim is installed from, if that is any help.
This issue could be caused by the stale remnants of the packer installation. Like cache.
Do you know how Kali linux builds Nvim?
And do you get the same issue if you build Nvim from source?
Correction: I thought I was running NeoVIM installed from the package repo, which would have given me NeoVIM version 9.5, but it appears I was mistaken, and NeoVIM was manually built and installed with version 10.0.
I will pull updates from sources and perform another build. This will bump my minor version up from 10 to 10.2.
Unfortunately, the same error is rearing its ugly head when Pckr Sync is called.
Error executing luv callback:
...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:29: The coroutine failed with this message: vim/shared.lua:0: s: expected string, got nil
stack traceback:
[C]: in function 'error'
vim/shared.lua: in function 'validate'
vim/shared.lua: in function 'gsplit'
vim/shared.lua: in function 'split'
.../share/nvim/pckr/pckr.nvim/lua/pckr/plugin_types/git.lua:276: in function 'resolve_tag'
.../share/nvim/pckr/pckr.nvim/lua/pckr/plugin_types/git.lua:317: in function 'checkout'
.../share/nvim/pckr/pckr.nvim/lua/pckr/plugin_types/git.lua:508: in function 'update'
.../share/nvim/pckr/pckr.nvim/lua/pckr/plugin_types/git.lua:552: in function 'updater'
...os/.local/share/nvim/pckr/pckr.nvim/lua/pckr/actions.lua:229: in function <...os/.local/share/nvim/pckr/pckr.nvim/lua/pckr/actions.lua:219>
stack traceback:
[C]: in function 'error'
...ser/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:29: in function 'cb'
...ser/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:68: in function 'callback'
...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/jobs.lua:25: in function 'on_exit'
/usr/local/share/nvim/runtime/lua/vim/_system.lua:300: in function </usr/local/share/nvim/runtime/lua/vim/_system.lua:270>
Press ENTER or type command to continue I am going to be looking into this some more. I just got a feeling it is somehow something small that is causing the error message to generate.
I also share this issue, running Fedora41. It may be of note that coroutine.running() seems to never return nil on my build, even in my init.lua. I don't know what the assert is there for, so I can't promise stability, but commenting out the assert allowed pckr to be usable again.
I'm guessing fedora builds LuaJIT with 5.2 compat enabled.
Might not be the same issue as everyone else. People see async in the error and just think it's the same thing even though the error message is different.
hm, interesting, apologies if this isn't the same issue, but the error appeared to stem from the same line, async.lua:108.
Running :Pckr sync produces the following:
Error executing Lua callback: ...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:108: assertion
failed!
stack traceback:
[C]: in function 'assert'
...user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/async.lua:108: in function 'cmd_func'
...e/user/.local/share/nvim/pckr/pckr.nvim/lua/pckr/cli.lua:89: in function <...e/user/.local/sha
re/nvim/pckr/pckr.nvim/lua/pckr/cli.lua:74>
I'm guessing fedora builds LuaJIT with 5.2 compat enabled.
Wait, wait, hold it... Noticed I was running LuaJit 5.1, and had suspected this minor was too low. By coincidence, the update to 5.2 has arrived and is being upgraded now. Well, see if this makes any difference.
Neovim needs to be built with Lua 5.1. nothing newer. And preferably LuaJIT. I know fedora has packaged LuaJIT with a 5.2 compat flag enabled which can cause issues (like this).
I shouldn't have been so eager to respond, regardless of the eagerness to find a solution to the problem. Yes, Kali did upgrade to Luajit 5.2, but this would have no effect on the build of nvim as long as luajit 5.1 is set as the requirement. Which it is in cmake/FindLuaJit.cmake.
cmake/FindLuajit.cmake
find_path2(LUAJIT_INCLUDE_DIR luajit.h
PATH_SUFFIXES luajit-2.1)
list(APPEND LUAJIT_NAMES libluajit libluajit-5.1)
list(APPEND LUAJIT_NAMES luajit-5.1)Furthermore, the init.el file was copied from Kali Linux to my OpenBSD desktop for testing. The OpenBSD distribution of NeoVIM is maintained with a more recent release of NVIM, so it is simply installed from the package manager. Regardless of being on a completely different operating system, and installed onto that system in a completely different manner, the same set of errors occurred. This rules out completely, or in the least significant lowers, the chance of the error being derived from an improper compilation method.
There still is the potential for the error being a result of the configuration file itself, which has been reviewed several times without finding fault. Admittedly, the file needs to be cleaned up, but was sound enough to run without error previously. To allow for testing it out, I have created a public gist with the contents of it.
https://gist.github.com/anoduck/643c955ff98188b19e206d9ce34a1341
Using it should reproduce the error seen and reported on this thread, and that error should be encountered upon first run.
Below is the screenshot of the error occurring on the first run on my OpenBSD Desktop.
So, now we have a means to reproduce the error and therefore can work towards its elimination.
Also note LuaJIT can be built with some 5.2 features using -DLUAJIT_ENABLE_LUA52COMPAT (see https://luajit.org/extensions.html). If it has then coroutine.running() will never be nil.
I know fedora in the past has packaged LuaJIT with this flag.
Oh just looked at your error. It has nothing to do with async.lua, the problem is in git.lua line 276. The tag resolution logic probably has an issue
This is not the same as the issue reported in the first post. People seem to keep getting thrown off by the error coming from async.lua, even though that's just where it is being caught and reported.
@lewis6991 Do you want me to open up a different issue report?
I've done a large overhaul in #42 and I think this issue has become quite stale with lots of other users using it to report other problems. Closing and locking. Please raise more specific issues with enough information to debug.
@sage-etcher: your issue should be fixed in dec2361