alphatroya
commented
3 years ago Same issue here, appear after updating to last version by :PackerSync. Found a culprit by repeatedly disabling plugins one by one.
Closed Mange closed 1 year ago
alphatroya
commented
3 years ago Same issue here, appear after updating to last version by :PackerSync. Found a culprit by repeatedly disabling plugins one by one.
TimUntersberger
commented
3 years ago Do you see a series of @ and junk inside the command line of vim before you crash? I sometimes encounter this myself when I print something on startup.
Mange
commented
3 years ago Do you see a series of
@and junk inside the command line of vim before you crash? I sometimes encounter this myself when I print something on startup.
I do not. Running without a debugger crashes Neovim without me even seeing a single frame of the TUI. It just had time to enable raw mode so I have to run reset afterwards.
In debugger, everything looks like it should except for the error message in the message line, then it crashes back to the shell again after confirming the error message with Enter.
TimUntersberger
commented
3 years ago @Mange Does it also crash if you manually call the setup function after neovim has started?
egidijusz
commented
3 years ago Not Mange, but have the same problem (also narrowed it down to Neogit).
No, it does not crash nvim if I manually do lua require('neogit').
egidijusz
commented
3 years ago Hmm, it seems neogit works without require'ing it. Removing require('neogit)` from my configs stops the crashes (and neogit still works). :shrug:
casprwang
commented
3 years ago Adding another observation: after SIGABRT I'm seeing my shell(zsh or bash)'s stdout getting distorted.
caenrique
commented
3 years ago Same here. Having problems also when loading a session. It was a pain to find the culprit. For me it's displaying some error messages related to plenary:
...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14:
The coroutine failed with this message:
.../.config/nvim/lua/plenary/async/util.lua: No such file or directoryIs everyone of you using unix?
caenrique
commented
3 years ago I observed the same behaviour in MacOS 11.5.2 and fedora 34
gstewart
commented
3 years ago I'm on Ubuntu-20.04. I saw the same as others, it would crash on start when I tried to open with a file from the current directory. The shell output was messed up afterwards, in that newlines didn't seem to show correctly (zsh).
After I uninstalled neogit and reinstalled, it stopped crashing and started reporting the error message:
...ck/packer/start/plenary.nvim/lua/plenary/async/async.lua:14:
The coroutine failed with this message:
.../.config/nvim/lua/plenary/async/util.lua: No such file or directoryIt seems to be after 2a9ce6bbe682c31dbd5cd59214eb0ae93dab4ab6. If I add that back in (specifically the dispatch_refresh), it doesn't happen.
I've also found that if I configure it to load after any other plugins that use plenary, it doesn't have the error either.
casprwang
commented
3 years ago this might also help: I'm not seeing the error when the current directory is outside of version control. Eg. if "/.git" does not exist, I can execute "nvim filepath" from "/"
TimUntersberger
commented
3 years ago This is really weird. I encountered this issue just now without a filename argument and after removing the setup call and readding it, it suddenly works again.
@Conni2461 do you know whether this could be a bug in plenary?
Conni2461
commented
3 years ago I dont think we have a bug in plenary here. I cant reproduce this with installing neogit in my config or with a minimal rc. Has someone actually reproduce this in a minimal rc? Because so far i dont see a mention here.
Also whats wheird is this part. Why does a packer/start/plenary.nvim look for a file in .config/nvim/lua/plenary/async/util.lua. Something is wrong here. And the vim.lua:63: i am seeing indicates that this happens when nvim tries to load packages. function vim._load_package(name) is the function.
Can someone, who experiences this bug, test with a minimal rc like this. nvim -nu minimal.rc foo.txt
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])
local package_root = "/tmp/nvim/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
require("packer").startup({
{
"wbthomason/packer.nvim",
{
"TimUntersberger/neogit",
requires = {
{ "nvim-lua/plenary.nvim" },
{ "sindrets/diffview.nvim" },
},
config = function()
print("loaded neogit")
require("neogit").setup()
end,
},
},
config = {
package_root = package_root,
compile_path = install_path .. "/plugin/packer_compiled.lua",
display = { non_interactive = true },
},
})
end
if vim.fn.isdirectory(install_path) == 0 then
print("Installing neogit and dependencies.")
vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()@TimUntersberger i advice you to switch to a minimal rc bug template otherwise its impossible to track down issues. See telescope
Also good to know what nvim --version outputs. Are people testing here with 0.5 release or currently nightly
Mange
commented
3 years ago I'll test out the minimal RC shortly. Hopefully today.
I worked around it by deferring the setup to later.
use {
"TimUntersberger/neogit",
requires = {
{"nvim-lua/plenary.nvim"},
{"sindrets/diffview.nvim"},
},
config = function()
-- Extremely temporary hack to get nvim to not crash on startup.
-- Will debug this problem and report upstream. Seems to be related to
-- plenary loading its luv or async module incorrectly on startup.
vim.defer_fn(
function()
require("neogit").setup {
-- ...
}
end,
10
)
end
}I think it might be a load order issue. As soon as everything has finished loading then there is no issue.
To everyone talking about the shell misbehaving, that is completely normal. Vim will enter terminal raw mode in order to draw the UI, with the expectation of restoring it back to normal terminal mode on exit. Since vim hard crashes, it never instructs the terminal to go back to normal mode. Just run the reset command to restore everything back to normal.
This happens a lot while developing TUI programs in non-managed languages like C and Rust. 🥲
I am running nightly.
TimUntersberger
commented
3 years ago I dont think we have a bug in plenary here. I cant reproduce this with installing neogit in my config or with a minimal rc. Has someone actually reproduce this in a minimal rc? Because so far i dont see a mention here.
Just tried using the minimal config and can't reproduce it either. Also thank you @Conni2461 for the issue template suggestion and thank you for your time!
mkubasz
commented
3 years ago @TimUntersberger Same from my side. When I go to directory when was git init called after that crashed.
fish: Job 1, 'nvim $argv' terminated by signal SIGABRT (Abort)
TimUntersberger
commented
3 years ago Same from my side
@mkubasz with the minimal config? https://github.com/TimUntersberger/neogit/issues/206#issuecomment-915213805
KingMichaelPark
commented
3 years ago I am getting the same issue as in this post but switching the init.lua to the minimal config and the crash does go away. It must be clashing with something else. I will see if I can pinpoint what it is as well.
KingMichaelPark
commented
3 years ago packer/start/plenary.nvim/lua/plenary/async/async.lua:14: The coroutine failed with this message: vim.lua:64: cannot open /home/mike/.config/nvim/lua/plenary/async/util.lua: No such file or directoryNow searching, this file does exist but here:
.local/share/nvim/site/pack/packer/start/plenary.nvim/lua/plenary/async/util.lua
So when I symlink that file there: I then get an error message saying
The coroutine failed with this message: vim.lua:64: cannot open /home/mike/.config/nvim/lua/plenary/async/async.lua: No such file or directoryWhich suggests to me that plenary is referencing a local path that is getting confused somehow instead of pointing to the right directory to load these.
So let me reconfigure packer and make sure it isn't that. It isn't really that big an issue because the plugin still works if you don't call the set up at all, but I only noticed this when I couldn't get the diffview integration to load.
KingMichaelPark
commented
3 years ago I added this to my init.lua
if pcall(require, 'plenary') then
RELOAD = require('plenary.reload').reload_module
R = function(name)
RELOAD(name)
return require(name)
end
endand updated my lua/plugins.lua to be:
local fn = vim.fn
local install_path = fn.stdpath('data')..'/site/pack/packer/start/packer.nvim'
if fn.empty(fn.glob(install_path)) > 0 then
fn.system({'git', 'clone', '--depth', '1', 'https://github.com/wbthomason/packer.nvim', install_path})
vim.cmd 'packadd packer.nvim'
end
-- Only required if you have packer configured as `opt`
vim.cmd [[packadd packer.nvim]]
return require('packer').startup(function()
use {'wbthomason/packer.nvim'}
use {'folke/tokyonight.nvim'}
use {
'kristijanhusak/orgmode.nvim',
config = function()
require('orgmode').setup({
org_agenda_files = {'~/Documents/org/*'},
org_default_notes_file = '~/Documents/org/notes.org'
})
end
}
use {'mcchrish/nnn.vim'}
use {'nvim-telescope/telescope-fzf-native.nvim', run = 'make'}
use {
'nvim-telescope/telescope.nvim',
requires = {{'nvim-lua/plenary.nvim'}}
}
use {'fisadev/vim-isort'}
use {'TimUntersberger/neogit',
requires = {
'nvim-lua/plenary.nvim',
'sindrets/diffview.nvim'
},
config = function()
require("neogit").setup(
{
integrations = {
diffview = true
}
}
)
end
}
use {'ambv/black'}
use {'srstevenson/vim-topiary'}
use {'nvim-treesitter/nvim-treesitter', run = ':TSUpdate'}
use {'neovim/nvim-lspconfig'}
use { 'ms-jpq/coq_nvim', branch = 'coq'}
use { 'ms-jpq/coq.artifacts', branch= 'artifacts'}
use {
'hoob3rt/lualine.nvim',
requires = {'kyazdani42/nvim-web-devicons', opt = true},
config = function()
require('lualine').setup({options = {theme = 'tokyonight'}})
end
}
use {'dinhhuy258/git.nvim', config = function() require('git').setup() end}
use {
'lewis6991/gitsigns.nvim',
requires = {'nvim-lua/plenary.nvim'},
}
use {'b3nj5m1n/kommentary'}
end)And it seems to work without failing now. I am not sure what has actually changed but it seems reloading plenary and a slight tweak to the packer stuff at the top for the install location addressed the issues. Sorry I can't be of more help
Mange
commented
3 years ago I'm testing this on a different machine now, but there's also been some time since this was reported. Now if I remove my workaround, this happens:
:messagesI'm slowly working towards finding what causes the error to appear in a minimal config. But at least I cannot get it to crash anymore on this machine with my full config.
Mange
commented
3 years ago I am not able to reproduce, even when I inline most of my config in the minimal example. It's almost like the minimal example changes the setup of the pack and runtime paths in a way to not trigger it... Or something along those lines.
I need to get to bed now. I'll try once more later where I move from the other direction. I managed to get it to crash consistently with just this config:
-- init.lua
require("neogit") -- Comment out and Neovim does not crashI had not run PackerSync, since I didn't want to ruin my Neovim when I reverted the file changes, but when I started nvim <a file> it would then crash every time. I made the generated packer.vim file not load any other plugins except for itself, but I think Vim would auto-include all plugins anyway since they are in the start site.
I need to isolate this part later. Actually delete plugins on disk until it stops happening.
TimUntersberger
commented
3 years ago I am not able to reproduce, even when I inline most of my config in the minimal example. It's almost like the minimal example changes the setup of the pack and runtime paths in a way to not trigger it... Or something along those lines.
So basically not using packer solves the problem? Do you have any lazy loading enabled?
Mange
commented
3 years ago So basically not using packer solves the problem?
I don't see how we could reach that conclusion at this time.
Do you have any lazy loading enabled?
No.
TimUntersberger
commented
3 years ago I don't see how we could reach that conclusion at this time.
Oh my god, sorry. I forgot that we are actually using packer in the minimal config. 🤦♂️
Mange
commented
3 years ago I gave it another go. I've managed to make my own little vim config pretty small now and can reliably replicate the error. However, when I try to adjust it for the minimal config setup then it does not happen. (Again, pointing towards this being a heisenbug)
Assume packer.nvim is already installed in the correct place too.
If I then start nvim and run PackerCompile and then PackerSync and restart, it's in a vulnerable state. Starting nvim a_file.txt will crash, while without a file is fine.
I've marked each line that you can remove to get rid of the problem behavior with a ☣️ symbol. For the neogit lines, the symbol mean that you can both remove the entire plugin and just the config from it to prevent the bug from happening.
Each change in lua/plugin.lua must be followed with a PackerCompile and a PackerSync and then a restart. In order to make this debugging easier for me, I edited through a clean config where I set up autocommands to always run this every time I saved, then I tested in a different terminal so I never had to restart my working Neovim.
I found that the autocommand listed above was required for the problem to happen for me. I could change it around a bit, but if it didn't call :lua then the problem also disappeared.
I then tried moving this over to the minimal example. Even with require("plugin"), so I had to add . to runtimepath.
As I said before, this does not trigger the error and work like it should.
I'll now try to see if there are other files in my autoload path that are important to trigger the error. Perhaps something in my ftdetect or something…
Just wanted to post an update with what I've found so far.
tl;dr I still have not replicated the error in the minimal rc, but I've minimized my own config a lot. Requires:
dashboard-nvimtelescopeneogitneogit's setup()WinEnter,BufEnter autocommand that calls anything with :lua
yggdr
commented
3 years ago FYI, I just ran into the same problems. I reduced my config to this:
~/.config/nvim/init.lua
local install_path = vim.fn.stdpath'data'..'/site/pack/packer/start/packer.nvim'
if vim.fn.empty(vim.fn.glob(install_path)) > 0 then
vim.fn.system{'git', 'clone', 'https://github.com/wbthomason/packer.nvim',
install_path} vim.api.nvim_command 'packadd packer.nvim'
end
require'neogit'.setup{}~/.config/nvim/lua/plugins.lua
return require'packer'.startup(function()
use 'wbthomason/packer.nvim'
use {'TimUntersberger/neogit', requires={'nvim-lua/plenary.nvim'}}
end)As soon as neovim reads or writes a file, it crashes:
nvim some_existing_file -> crash
nvim -> neovim starts. :edit some_existing_file -> crash
nvim some_nonexisting_file -> Enter some text, :wq -> writes file content, then crashes
Only just now, when playing around with it, it managed to not crash when writing to a new file.
I just experimented a bit more, now I was able to write 1 single byte to a new file and open it (nvim thefile) successfully again. I then added another few bytes, :wq, open again, etc. until I reached 193 bytes, then it crashed again upon opening it. But in another testrun, it crashed a bit before the 190 byte mark, so that seems not a hard limit.
Running on FreeBSD 13.0-p4, neovim 0.5.0 from FreeBSD package:
nvim --version
NVIM v0.5.0
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wno-c11-extensions -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/wrkdirs/usr/ports/editors/neovim/work/.build/config -I/wrkdirs/usr/ports/editors/neovim/work/neovim-0.5.0/src -I/usr/local/include -I/usr/include -I/wrkdirs/usr/ports/editors/neovim/work/.build/src/nvim/auto -I/wrkdirs/usr/ports/editors/neovim/work/.build/include
Compiled by root@130amd64-default-job-09
Features: +acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM/sysinit.vim"
fall-back for $VIM: "/usr/local/share/nvim"
Run :checkhealth for more infoOkay, so it feels like I'm slowly going insane here…
I managed to remove almost all of my files and still replicate the error. Almost.
Here's my file tree:
t ~/.config/nvim
/home/mange/.config/nvim
├── ftdetect
│ └── foo.vim
├── init.lua
├── lua
│ └── plugins.lua
└── plugin
├── commands.vim
└── packer_compiled.luaSo here's the weird part. It will stop crashing if I:
ftdetect/foo.vim or plugin/commands.vimplugin/commands.vim (even a single letter; command, c, commands2, comand; ftdetect/foo.vim does not have this property)The next weird thing? plugin/commands.vim is just 34 blank lines. That's right. Blank lines. And if I remove a single line, it stops crashing. I discovered this when I was trying to reduce the actual file contents; deleting any line stopped the crashes, but clearing the line so it became empty maintained the error. Now it's just empty lines.
hexdump -c config/plugin/commands.vim
0000000 \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
*
0000020 \n \n
0000022Next weird thing? ftdetect/foo.vim is empty. It can have any name, but if I remove it neovim stops crashing.
I'll zip the whole deal up now. You should be able to unpack it somewhere, move your ~/.local/nvim over to and symlink in this config directory over and possibly get the crash you too. Or not.
I assume this is some sort of race condition that depends on a whole lot of variables, like I/O speed, memory, file system caching, and so on. Because the symptoms does not make sense at all!
TimUntersberger
commented
3 years ago @Mange normally when something as stupid as removing empty lines fixes a problem it almost always has to do with a race condition. Sadly I have no clue what could cause this.
zbindenren
commented
3 years ago I ran into the seme issue. Due to @gstewart hint I found a working configuration with:
use {
"TimUntersberger/neogit",
requires = { "sindrets/diffview.nvim", "nvim-lua/plenary.nvim" },
commit = "53772efc42263989d18d4a86c350b8b0e1f1b71b", -- https://github.com/TimUntersberger/neogit/issues/206
config = function() require("neogit").setup{
disable_commit_confirmation = true,
integrations = {
diffview = true
}
} end,
}I think the commit referenced by @gstewart lead to the issue people are experiencing.
Jimmyscene
commented
3 years ago Throwing in another workaround,
requiring plenary before requiring neogit seems to solve the issue
use({
"nvim-lua/plenary.nvim",
config = function()
require("plenary")
end,
})EDIT: Above fix only fixed the issue in some cases, it seems. I've since switched to lazy loading Neogit only when the Neogit command is called which has resolved it.
use({ "TimUntersberger/neogit", cmd="Neogit", config=....})
I have a hard time debugging this one, so any help would be appreciated. This is basically my symptoms:
When I start vim and then open a file, everything is okay.
When I open a file straight from the command line, Neovim crashes
This only happens as long as I have neogit enabled and loaded via Packer.nvim.
If I comment out the
configfunction, then no crash. And Neogit is of course also not set up.What can I do to help debug this? I'm not sure how to get a sensible crash dump. I tried
Then the editor does not crash right away; I first get a Lua error about it not being able to execute a luv callback: (with the file visible behind it)
(Translated from my locale)
Then when I press Enter to continue the prompt, I get
Honestly, this looks more and more like a Plenary problem to me. Perhaps Neogit is triggering something there that is not working well on my machine.
I think the backtrace shows it crashing inside a regexp parser. It's strange to me how it only happens when loading Neovim with a filename argument.