error attempt to get length of local 'prev_line' #24972

eyalk11 · 2023-09-01T16:38:31Z

Problem

Sometimes lsp client hangs and get

Error executing lua callback: ...rs\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp/sync.lua:177: attempt to get length of local 'prev_line' (a nil value)
stack traceback:
	...rs\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp/sync.lua:177: in function 'compute_start_range'
	...rs\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp/sync.lua:408: in function 'compute_diff'
	C:\Users\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp.lua:446: in function 'incremental_changes'
	C:\Users\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp.lua:639: in function 'send_changes'
	C:\Users\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp.lua:1577: in function <C:\Users\ekarni\Neovim\share\nvim\runtime/lua/vim/lsp.lua:1564>

The file is python file. I use lsp_config and nvim-lsp-installer with copilot , null-ls , pyright, pylsp as lsp clients. I don't know which failed.
I got this message constantly when writing a line (on every char). It got OK eventually.

Steps to reproduce

Unkown

Expected behavior

This shouldn't happen

Neovim version (nvim -v)

NVIM v0.9.1 Build type: RelWithDebInfo LuaJIT 2.1.0-beta3 Compilation: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe /MD /Zi /O2 /Ob1 -W3 -wd4311 -wd4146 -DUNIT_TESTING -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_WIN32_WINNT=0x0602 -DMSWIN -DINCLUDE_GENERATED_DECLARATIONS -ID:/a/neovim/neovim/.deps/usr/include/luajit-2.1 -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/build/src/nvim/auto -ID:/a/neovim/neovim/build/include -ID:/a/neovim/neovim/build/cmake.config -ID:/a/neovim/neovim/src -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include -ID:/a/neovim/neovim/.deps/usr/include system vimrc file: "$VIM\sysinit.vim" fall-back for $VIM: "C:/Program Files (x86)/nvim/share/nvim" Run :checkhealth for more info

Vim (not Nvim) behaves the same?

didnt try

Operating system/version

windows

Terminal name/version

nvim-qt

$TERM environment variable

''

Installation

stable probably

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

clason · 2023-09-01T17:03:30Z

Please fill out the template correctly; those fields are there for a reason. (For example, where did you get the nightly from? And why does the version then claim NVIM 0.9.1, which is stable?)

We also need at least some context to be able to debug this: What server? What file? How do you start the server (plugins?)...

eyalk11 · 2023-09-01T17:19:38Z

Hmm, fixed. Is it OK now?

clason · 2023-09-01T17:28:27Z

Sorry, no, that's not nearly enough for us to go on.

eyalk11 · 2023-09-01T17:30:26Z

I don't think I know any more useful details. Is the LSP log useful? I am not sure I know in what time this has happened. Anything else? What server? What file? I can answer about the file but it won't help you. It is a python file. I don't know the server.

clason · 2023-09-01T17:36:10Z

The point is to create a minimal(!) config and example that somebody else can try at home. (Server == LSP server; there's multiple for python.)

First step would be to remove copilot from the equation.

monopoly-db · 2023-10-08T00:12:59Z

Running into this as well.
MacOS Monterey.

Error executing lua callback: /Users/xxxxx/share/nvim/runtime/lua/vim/lsp/sync.lua:248: attempt to get length of local 'prev_line' (a nil value)                                                                                                                                                                    
stack traceback:
        /Users/xxxxx/share/nvim/runtime/lua/vim/lsp/sync.lua:248: in function 'compute_end_range'
        /Users/xxxxx/share/nvim/runtime/lua/vim/lsp/sync.lua:419: in function 'compute_diff'
        /Users/xxxxx/share/nvim/runtime/lua/vim/lsp.lua:446: in function 'incremental_changes'
        /Users/xxxxx/share/nvim/runtime/lua/vim/lsp.lua:639: in function 'send_changes'
        /Users/xxxxx/share/nvim/runtime/lua/vim/lsp.lua:1576: in function </Users/xxxxx/share/nvim/runtime/lua/vim/lsp.lua:1563>

:version
NVIM v0.9.2
Build type: Release
LuaJIT 2.1.1692716794

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

 Detected filetype:   rust
 
 2 client(s) attached to this buffer: 
 
 Client: diagnosticls (id: 11, bufnr: [35, 21, 314, 223, 47, 132, 56, 36])
 	filetypes:       
 	autostart:       true
 	root directory:  /Users/xxxxx/...
 	cmd:             diagnostic-languageserver --stdio
 
 Client: rust_analyzer (id: 12, bufnr: [47, 314, 36])
 	filetypes:       rust
 	autostart:       true
 	root directory:  /Users/xxxx/...
 	cmd:             /Users/xxxx/.cargo/bin/rust-analyzer

Found these messages in LSP log:

[ERROR][2023-10-07 19:51:51] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/xxxxx/.cargo/bin/rust-analyzer"	"stderr"	'[ERROR rust_analyzer::dispatch] unknown request: Request { id: RequestId(I32(6088)), method: "workspace/executeCommand", params: Object {"title": String("triggerParameterHints"), "command": String("rust-analyzer.triggerParameterHints")} }\n'
[ERROR][2023-10-07 19:52:07] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/xxxxx/.cargo/bin/rust-analyzer"	"stderr"	'[ERROR rust_analyzer::dispatch] unknown request: Request { id: RequestId(I32(6167)), method: "workspace/executeCommand", params: Object {"title": String("triggerParameterHints"), "command": String("rust-analyzer.triggerParameterHints")} }\n'
[ERROR][2023-10-07 19:52:59] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/xxxxx/.cargo/bin/rust-analyzer"	"stderr"	'[ERROR rust_analyzer::dispatch] unknown request: Request { id: RequestId(I32(6366)), method: "workspace/executeCommand", params: Object {"title": String("triggerParameterHints"), "command": String("rust-analyzer.triggerParameterHints")} }\n'
[ERROR][2023-10-07 19:53:34] .../vim/lsp/rpc.lua:734	"rpc"	"/Users/xxxxx/.cargo/bin/rust-analyzer"	"stderr"	'[ERROR rust_analyzer::dispatch] unknown request: Request { id: RequestId(I32(6480)), method: "workspace/executeCommand", params: Object {"title": String("triggerParameterHints"), "command": String("rust-analyzer.triggerParameterHints")} }\n'

Gets triggered every time I write a Rust file. This seems to be accompanied by this error in LSP Log as well:

[ERROR][2023-10-07 20:18:48] ...lsp/handlers.lua:535	"Notification handler 'textDocument/didChange' failed with message: TextDocument.update: document must be created by TextDocument.create"
[ERROR][2023-10-07 20:18:50] ...lsp/handlers.lua:535	"Notification handler 'textDocument/didChange' failed with message: TextDocument.update: document must be created by TextDocument.create"
[ERROR][2023-10-07 20:19:01] ...lsp/handlers.lua:535	"Notification handler 'textDocument/didChange' failed with message: TextDocument.update: document must be created by TextDocument.create"
[ERROR][2023-10-07 20:19:02] ...lsp/handlers.lua:535	"Notification handler 'textDocument/didChange' failed with message: TextDocument.update: document must be created by TextDocument.create"

Restarting the editor fixes the problem.

themightyoarfish · 2023-11-06T16:10:27Z

I have the same problem on neovim 0.9.1 from homebrew, with lspconfig, coc-clangd. It happens seemingly all the time, whenever I edit the current buffer, switch to a new one and then edit in that. Specifically, editing inside a C++ function argument list seems to trigger this problem, not every edit otherwise.

Error executing lua callback: ...lar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp/sync.lua:177: attempt to get length of local 'prev_line' (a nil value)
stack traceback:
        ...lar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp/sync.lua:177: in function 'compute_start_range'
        ...lar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp/sync.lua:408: in function 'compute_diff'
        ...w/Cellar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp.lua:446: in function 'incremental_changes'
        ...w/Cellar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp.lua:639: in function 'send_changes'
        ...w/Cellar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp.lua:1577: in function <...w/Cellar/neovim/0.9.1/share/nvim/runtime/lua/vim/lsp.lua:1564>

The error happens as soon as I include this code in init.vim, just including lspconfig alone does not trigger it

call dein#add('neovim/nvim-lspconfig')
function! LspAttached() abort
"   empty
endfunction

lua <<EOF
require("lspconfig").clangd.setup({
  on_attach = function()
    vim.call('LspAttached')
  end
})
EOF

(I'm using dein package manager)

themightyoarfish · 2023-11-06T16:55:31Z

In my case, I could narrow it down to the presence or absence of this block:

augroup cppbindings
    autocmd!
    autocmd BufReadPre,FileReadPre *.hpp set ft=cpp
    autocmd BufReadPre,FileReadPre *.cpp set ft=cpp
augroup END

when included, the error occurs. When not included, no problem.

iurimateus · 2024-04-07T15:25:44Z

Possibly related #16259

zeertzjq · 2024-04-10T00:52:12Z

The problem with DAP has been fixed by #28260

icholy · 2024-04-16T13:53:57Z

I wrote a simple keylogging plugin in hopes of getting more context next time I hit this bug: https://github.com/icholy/keylog.nvim

@themightyoarfish @monopoly-db how frequently do you hit this issue? I'm only getting it once every 2 weeks recently. If it's frequent, can you share more details about your setups/configurations?

themightyoarfish · 2024-04-16T13:55:55Z

I have not ever had this after removing the config block i wrote above, but i think it occurred often, daily at least.

igor47 · 2024-04-16T20:11:49Z

i think this happens to me whenever i suspend neovim and update the files outside the editor. for instance, via changing git branches, or doing a rebase. when i resume neovim, this is triggered. but i haven't had a chance to get down to reproducible test case

michelesr · 2024-04-16T20:41:15Z

i think this happens to me whenever i suspend neovim and update the files outside the editor. for instance, via changing git branches, or doing a rebase. when i resume neovim, this is triggered. but i haven't had a chance to get down to reproducible test case

This makes sense. I'm not able to reproduce it reliably, but I think it also happened when running formatters or other commands that modify the files (e.g. !ruff format %): usually neovim reloads them, but then LSP goes crazy... some LSPs (like pyright) also don't handle incremental sync very well (see #15532), sometimes they just report wrong errors in the diagnostic and is sufficient to do :e to resync them, something they get crazy and start popping this error message a lot, and then you need something like :LspRestart to fix them.

icholy · 2024-04-17T20:15:49Z

@igor47 I've managed to reproduce it consistently by stopping the nvim --embed process and changing the files on disk:

$ ps aux | grep nvim | grep embed
icholy    181496  1.2  0.0  28640 21772 ?        Ssl  16:14   0:00 nvim --embed
$ kill -s STOP 181496
$ # modify file
$ kill -s CONT 181496

igor47 · 2024-05-04T19:03:48Z

definitely not easy to get a repro, but it's a big issue for me. i end up restarting neovim all the time, which gets me out of flow and loses my context of open buffers and cursor positions and tabs. pretty annoying. here's a repro using my neovim config, on the latest neovim and with all plugins recently updated. managed to trigger it by echoing into the buffer from outside neovim, but the behavior is very inconsistent -- sometimes, neovim will prompt me to reload the file. sometimes it will just reload it. and sometimes, it'll go into crash mode. you can see me restarting lsp, which doesn't fix it but somehow editing a different part of the file does fix it? sometimes i can fix it by :e and sometimes that doesn't work either. 🤷

lspcrash.webm

nvim --version
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1713773202

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

igor47 · 2024-05-04T20:05:35Z

ok here's a minimal repro: https://github.com/igor47/nvimbug

i'm using only a very minimal set of plugins -- mason and lspconfig , with lazy to install them. seems to repro pretty reliably:
Screencast from 2024-05-04 13-02-24.webm

icholy · 2024-05-04T21:32:23Z

I can consistently get a de-sync with the following repro. https://github.com/icholy/nvim-lsp-bug-3

I was doing some more experimenting and found the following:

The bug only occurs when there are at least 2 LSPs attached.
The second LSP doesn't need to do anything other than advertise the text document sync capability.
- I created this bare-bones LSP server which does just that https://github.com/icholy/dummylsp/tree/master

I created a much smaller repro with the dummy LSP: https://github.com/icholy/nvim-lsp-bug-3/tree/dummylsp

Config:

local gopls = vim.lsp.start_client({ name = "gopls", cmd = { "gopls", "serve" } })
local dummy = vim.lsp.start_client({ name = "dummy", cmd = { "dummylsp" } })

vim.api.nvim_create_autocmd("FileType", {
	pattern = { "go" },
	callback = function()
		vim.lsp.buf_attach_client(0, gopls)
		vim.lsp.buf_attach_client(0, dummy)
	end
})

Steps:

go install golang.org/x/tools/gopls@latest
go install github.com/icholy/dummylsp@latest
nvim --clean -u init.lua test.go
:!echo " " >> test.go
:lua vim.lsp.buf.format()

icholy · 2024-05-12T18:31:46Z

If anyone here is able to test #28721 that would be appreciated.

edit: I've been using my fork as my daily driver for a week and have no issues.

Frederick888 · 2024-05-20T03:01:34Z

@icholy I was able to consistently reproduce this issue when resolving conflicts during a git rebase with conflict-marker.vim.

Error detected while processing function conflict_marker#compromise:
line    7:
Error executing lua callback: ...ar/neovim/0.10.0/share/nvim/runtime/lua/vim/lsp/sync.lua:380: attempt to get length of a nil value
stack traceback:
        ...ar/neovim/0.10.0/share/nvim/runtime/lua/vim/lsp/sync.lua:380: in function 'compute_range_length'
        ...ar/neovim/0.10.0/share/nvim/runtime/lua/vim/lsp/sync.lua:443: in function 'compute_diff'
        ....10.0/share/nvim/runtime/lua/vim/lsp/_changetracking.lua:106: in function 'incremental_changes'
        ....10.0/share/nvim/runtime/lua/vim/lsp/_changetracking.lua:311: in function 'send_changes_for_group'
        ....10.0/share/nvim/runtime/lua/vim/lsp/_changetracking.lua:348: in function 'send_changes'
        .../Cellar/neovim/0.10.0/share/nvim/runtime/lua/vim/lsp.lua:553: in function <.../Cellar/neovim/0.10.0/share/nvim/runtime/lua/vim/lsp.lua:548>

The issue was gone after applying your patch. Thank you!

eyalk11 added the bug issues reporting wrong behavior label Sep 1, 2023

clason added needs:response waiting for reply from the author needs:repro We need minimal steps to reproduce the issue lsp labels Sep 1, 2023

github-actions bot removed the needs:response waiting for reply from the author label Sep 1, 2023

themightyoarfish mentioned this issue Nov 6, 2023

Error executing lua callback: ... attempt to get length of local 'line' (a nil value) when editting new files #17615

Closed

This comment was marked as resolved.

Sign in to view

neovim deleted a comment from mortezadadgar Jan 13, 2024

This comment was marked as resolved.

Sign in to view

icholy mentioned this issue Apr 7, 2024

fix(prompt): emit change event for prompt newline #28217

Closed

This was referenced Apr 8, 2024

Attempt to get length of local 'prev_line' (a nil value) mfussenegger/nvim-dap#562

Closed

fix(prompt): emit change event for prompt newline #28260

Merged

zeertzjq added lsp and removed lsp labels Apr 10, 2024

mehalter mentioned this issue Apr 21, 2024

Recurring error with HTML file AstroNvim/AstroNvim#2547

Closed

3 tasks

This comment was marked as outdated.

Sign in to view

icholy mentioned this issue May 12, 2024

fix(lsp): update the changetracking buffer state on reload #28721

Closed

icholy mentioned this issue May 21, 2024

fix(lsp): detach all clients on_reload to force buf_state reload #28875

Merged

mfussenegger closed this as completed in #28875 May 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

error attempt to get length of local 'prev_line' #24972

error attempt to get length of local 'prev_line' #24972

eyalk11 commented Sep 1, 2023 •

edited

clason commented Sep 1, 2023

eyalk11 commented Sep 1, 2023

clason commented Sep 1, 2023

eyalk11 commented Sep 1, 2023 •

edited

clason commented Sep 1, 2023

monopoly-db commented Oct 8, 2023 •

edited

themightyoarfish commented Nov 6, 2023 •

edited

themightyoarfish commented Nov 6, 2023

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

iurimateus commented Apr 7, 2024

zeertzjq commented Apr 10, 2024 •

edited

icholy commented Apr 16, 2024

themightyoarfish commented Apr 16, 2024

igor47 commented Apr 16, 2024

michelesr commented Apr 16, 2024 •

edited

icholy commented Apr 17, 2024 •

edited

This comment was marked as outdated.

igor47 commented May 4, 2024 •

edited

igor47 commented May 4, 2024

icholy commented May 4, 2024 •

edited

icholy commented May 12, 2024 •

edited

Frederick888 commented May 20, 2024

error attempt to get length of local 'prev_line' #24972

error attempt to get length of local 'prev_line' #24972

Comments

eyalk11 commented Sep 1, 2023 • edited

Problem

Steps to reproduce

Expected behavior

Neovim version (nvim -v)

Vim (not Nvim) behaves the same?

Operating system/version

Terminal name/version

$TERM environment variable

Installation

clason commented Sep 1, 2023

eyalk11 commented Sep 1, 2023

clason commented Sep 1, 2023

eyalk11 commented Sep 1, 2023 • edited

clason commented Sep 1, 2023

monopoly-db commented Oct 8, 2023 • edited

themightyoarfish commented Nov 6, 2023 • edited

themightyoarfish commented Nov 6, 2023

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

iurimateus commented Apr 7, 2024

zeertzjq commented Apr 10, 2024 • edited

icholy commented Apr 16, 2024

themightyoarfish commented Apr 16, 2024

igor47 commented Apr 16, 2024

michelesr commented Apr 16, 2024 • edited

icholy commented Apr 17, 2024 • edited

This comment was marked as outdated.

igor47 commented May 4, 2024 • edited

igor47 commented May 4, 2024

icholy commented May 4, 2024 • edited

icholy commented May 12, 2024 • edited

Frederick888 commented May 20, 2024

eyalk11 commented Sep 1, 2023 •

edited

eyalk11 commented Sep 1, 2023 •

edited

monopoly-db commented Oct 8, 2023 •

edited

themightyoarfish commented Nov 6, 2023 •

edited

zeertzjq commented Apr 10, 2024 •

edited

michelesr commented Apr 16, 2024 •

edited

icholy commented Apr 17, 2024 •

edited

igor47 commented May 4, 2024 •

edited

icholy commented May 4, 2024 •

edited

icholy commented May 12, 2024 •

edited