Bug: expected table, got function, after neovim was inactive for some time

[Gelio]

Self Checks

• [x] I'm using the latest lualine.
• [x] I didn't find the issue in exsisting issues or prs.

How to reproduce the problem

I don't have any good reproduction steps.

After leaving neovim idle for some time (> 5 minutes, but I didn't find a pattern as to when it happens), the following error is shown:

E5108: Error executing lua ...m/nvim-linux64/share/nvim/runtime/lua/vim/diagnostic.lua:704: opt[6.9283908576005e-310]: expected table, got function
stack traceback:
        [C]: in function 'error'
        vim/shared.lua:607: in function 'validate'
        ...m/nvim-linux64/share/nvim/runtime/lua/vim/diagnostic.lua:704: in function 'get'
        ...im-linux64/share/nvim/runtime/lua/vim/lsp/diagnostic.lua:344: in function 'get_count'
        ...line.nvim/lua/lualine/components/diagnostics/sources.lua:8: in function <...line.nvim/lua/lualine/components/diagnostics/sources.lua:7>
        ...line.nvim/lua/lualine/components/diagnostics/sources.lua:58: in function 'get_diagnostics'
        ...lualine.nvim/lua/lualine/components/diagnostics/init.lua:72: in function 'update_status'
        ...pack/packer/start/lualine.nvim/lua/lualine/component.lua:175: in function 'draw'
        .../packer/start/lualine.nvim/lua/lualine/utils/section.lua:26: in function 'draw_section'
        ...nvim/site/pack/packer/start/lualine.nvim/lua/lualine.lua:153: in function 'statusline'
        ...nvim/site/pack/packer/start/lualine.nvim/lua/lualine.lua:316: in function <...nvim/site/pack/packer/start/lualine.nvim/lua/lualine.lua:297>
Press ENTER or type command to continue

After that, lualine stops working and I am back to the default neovim statusline.

As I investigated the function calls, looks like there is nothing in lualine's code that is wrong here. The stacktrace mentions:

https://github.com/neovim/neovim/blob/04c7b550384b2246d37c1a893c0f858bc332cb8b/runtime/lua/vim/diagnostic.lua#L704-L707

and

https://github.com/neovim/neovim/blob/04c7b550384b2246d37c1a893c0f858bc332cb8b/runtime/lua/vim/lsp/diagnostic.lua#L339-L344

If I'm not mistaken, vim.validate is failing on this line https://github.com/neovim/neovim/blob/04c7b550384b2246d37c1a893c0f858bc332cb8b/runtime/lua/vim/shared.lua#L570 (given the format of the error message), which means that there is some property in the table passed to vim.validate that is a function?

This may not be caused by lualine at all and may be a bug in neovim, or caused by yet something else. I'm mainly posting here because this affects the status line and I wanted to see if any maintainer has a clue why it may happen or there are more people with this problem.

Aditional information

My lualine config: https://github.com/Gelio/ubuntu-dotfiles/blob/a730df8a97c147d4f74299992261155900ced47e/install/neovim/stowed/.config/nvim/lua/plugins.lua#L117-L163

I'm running neovim nightly:

13:03 $ nvim -v
NVIM v0.6.0-dev+648-gfff882790
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -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/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az32-74

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/share/nvim"

Run :checkhealth for more info

---

Reported upstream:

• [x] https://github.com/neovim/neovim/issues/16501

[shadmansaleh]

This seems weird. I've never encountered anything like this. Can you check if you can reproduce it with nvim diagnostics source ?

On 0.6 you should use nvim source instead of nvim-lsp. nvim source gets diagnostics from new diagnostics api and nvim-lsp uses older vim.lsp.diagnostics (which is deprecated in 0.6)

I can see nothing wrong in lualine or neovims related codes that error seems impossible to happen because opts created as a table all the time but still fails as a function :/

[Gelio]

On 0.6 you should use nvim source instead of nvim-lsp. nvim source gets diagnostics from new diagnostics api and nvim-lsp uses older vim.lsp.diagnostics (which is deprecated in 0.6)

Thanks! I must have missed this. I'll switch to nvim source and see if the problem still occurs. If I don't encounter it for a week, I'll consider the problem solved

I can see nothing wrong in lualine or neovims related codes that error seems impossible to happen because opts created as a table all the time but still fails as a function :/

Yeah, same here. Btw. it may not be the opts parameter that is expected to be a table, but the vim.validate spec (which means either { opts, 't', true } or { bufnr, 'n', true } or there is some extra entry that is a function). I believe so because the error message has opt[%s] in it, and the only time it appears in vim.validate is this line which validates the spec itself, not the actual parameter. This makes it even weirder.

[williamboman]

On 0.6 you should use nvim source instead of nvim-lsp. nvim source gets diagnostics from new diagnostics api and nvim-lsp uses older vim.lsp.diagnostics (which is deprecated in 0.6)

Ah! I've been running into this error for quite some time and never figured out what was causing it. Maybe it could be good to do some sort of PSA on the neovim subreddit and perhaps even do some feature detection to inform people if they're using incompatible sources?

if vim.fn.has("nvim-0.6.0") and source == "nvim_lsp" then
  vim.notify("...", vim.log.levels.WARN)
end

[Gelio]

If I don't encounter it for a week, I'll consider the problem solved

Unfortunately, I've just hit the problem again after leaving neovim idle for around 45 minutes, even when using the nvim source (not nvim_lsp):

Should I report the problem in the neovim repo at this point?

[shadmansaleh]

perhaps even do some feature detection to inform people if they're using incompatible sources?

I was planing on deprecating nvim-lsp source after 0.6 release . It's been released few days ago. I think I'll wait a while more for most people to catch upto latest version .

Should I report the problem in the neovim repo at this point?

@Gelio yeah, you can open an issue there and see what gpanders & mjlbach thinks about this.

[gpanders]

I suspect (not know) that this could actually be a bug in LuaJIT itself. I cannot think of any possible reason this error should be occurring with the source code we have.

We can gather more clues by attempting to reproduce this bug on PUC 5.1 or OpenResty's fork of LuaJIT. @Gelio are you installing Neovim from source? If so, can you try rebuilding with the -DPREFER_LUA=ON CMake option (that will build with standard Lua 5.1 (not LuaJIT)) and try reproducing the issue?

[clason]

Would also help to have exact information about the environment:

• architecture (Intel/ARM/etc)
• platform (Debian/macOS/etc.)
• which version of Neovim (which exact repo/built from source)
• (which in particular will tell us the exact commit of LuaJIT used)

[shadmansaleh]

@williamboman can you provide these info since you can reproduce the issue ?

[williamboman]

Will do asap! On mobile atm. But generally I run fresh nightly builds on macOS M1 (ARM)

[clason]

Via homebrew or manually from a cloned repo? (I.e., with our LuaJIT commit, or homebrew's openResty fork?)

[Gelio]

@gpanders

@Gelio are you installing Neovim from source?

I am installing neovim by unpacking the nightly nvim-linux64.tar.gz into my /usr directory (symlinking using stow, to be precise). I am not compiling from source myself.

My install script is: https://github.com/Gelio/ubuntu-dotfiles/blob/master/install/neovim/install.sh

@clason

Would also help to have exact information about the environment:

• architecture (Intel/ARM/etc)
• platform (Debian/macOS/etc.)
• which version of Neovim (which exact repo/built from source)
• (which in particular will tell us the exact commit of LuaJIT used)

I am sure I have encountered it on the GCP VM:

OS: Ubuntu 20.04.3 LTS x86_64 Host: Google Compute Engine Kernel: 5.8.0-1038-gcp CPU: Intel Xeon (4) @ 2.800GHz

I don't know which LuaJIT commit the nightly uses, so I can't help with that.

17:17 $ nvim -v
NVIM v0.7.0-dev+662-g73b35ef10
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -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/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az87-350

Features: +acl +iconv +tui

I don't remember if I faced it on my laptop locally. I am trying to reproduce it locally (by leaving neovim idle for some time) and will let you know if that happens.

My laptop environment info, in case I am able to reproduce the problem

OS: Ubuntu 20.04.3 LTS x86_64 Host: 82JU Legion 5 15ACH6H Kernel: 5.11.0-41-generic CPU: AMD Ryzen 7 5800H with Radeon Graphics (16) @ 3.200GHz I have just fetched the latest nightly: ```sh 18:22 $ nvim -v NVIM v0.7.0-dev+662-g73b35ef10 Build type: RelWithDebInfo LuaJIT 2.1.0-beta3 Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -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/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include Compiled by runner@fv-az87-350 Features: +acl +iconv +tui ```

---

I will create an issue about this problem in the neovim repository within the next hour.

[clason]

I don't know which LuaJIT commit the nightly uses, so I can't help with that.

That's OK, if you use the nightly from the repo, I know which (the latest).

[Gelio]

Here is the issue I raised in the neovim repo: https://github.com/neovim/neovim/issues/16501

[williamboman]

Via homebrew or manually from a cloned repo? (I.e., with our LuaJIT commit, or homebrew's openResty fork?)

It's from a cloned repo. I ran into this error earlier today, running this build:

NVIM v0.7.0-dev+653-g7229afcd6
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by williamboman@Williams-MacBook-Air.local

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/opt/nvim/share/nvim"

Run :checkhealth for more info

[clason]

Gotcha. Then it's likely a recent LuaJIT change (possibly the compiled table traversal such as https://github.com/LuaJIT/LuaJIT/commit/c6f5ef649b645db9cf3d11d1b5c63602c49c6411, as @mjlbach suggested).

If you have a lot of spare time, you could bisect the LuaJIT dependency. 😬

[williamboman]

If you have a lot of spare time, you could bisect the LuaJIT dependency. 😬

Haha I wish I knew how to reproduce it. This happens so sporadically. The only common pattern I can think of, if I had to, is that it seems to only happen when I have a) multiple buffers open, and b) multiple buffers visible in a window.

[williamboman]

I just had this happen immediately after opening a neovim instance (and with only one buffer open). There's some reports in https://github.com/williamboman/nvim-lsp-installer/issues/277 that at first glance look very similar, although I have not had time to dig into it yet

[shadmansaleh]

I'm closing this since I haven't yet been able reproduce it .And it seems this doesn't occur for you any more either .