Neovim occasional hang/freeze when using ctrl-c to exit fzf-lua #1091
Comments
|
Can you elaborate more on the circumstances of the hang? Are you using There is a known issue which I opened upstream when using That’s the reason why I hard mapped Lines 237 to 241 in 5104ac1 You can also read my debugging comments and process in the comments: Lines 194 to 236 in 5104ac1 |
|
I think yes, but maybe there is another case, i'm going to observer. Thank you! Sometimes i see message like |
|
A good start would be some details on your setup:
Where does the message appear? |
|
Mac m1, fish shell and tmux See, i tried to save with When nvim completely stucked and fzf was opened (in this case i can't close nvim and i just close tmux pane). After that i open nvim one more time and press |
|
Also sometimes i got weird behaviour when fzf opened and i resize pane in tmux. |
This could not be related to fzf-lua as the code doesn’t have any auto commands running outside fzf-lua’s own buffers/windows.
Does this happen on other buffer types or only on terminal buffers?
Can you describe “weird behavior”? |
Another question, when you’re stuck when fzf-lua is open is it possible you exited to normal mode by mistake (some keybind)? What happens if you press When neovim is stuck if you look at the processes is neovim taking 100% CPU? |
No, nvim doesn't respond at all. Screenshot below after |
|
And after |
|
Else |
|
So can we say safely all of these are related to ctrl-c? If so we might have to wait for the upstream to be fixed. |
|
I noticed one more thing. Every time when i open fzf i got this log: |
You mean when you open fzf-lua or fzf in the shell? Where exactly does this message appear? |
|
Fzf-lua sure
here -> |
I’ll check but that might be totally normal, the headless wrapper deletes the temp dir at startup as it doesn’t need it, otherwise terminating fzf commands early may leave a lingering temp dir. |
Screen.Recording.2024-03-20.at.21.00.30.mov |
Ok, so the temp dir error is ok, it’s due to the above. |
|
Quite honestly @kaiphat, if it’s just happening on ctrl-c, there is not much I can do until neovim/neovim#20726 gets fixed. Try using Esc / Ctrl-q to exit fzf (instead of ctrl-c), if it doesn’t happen then it’s pretty much the same issue. |
|
I’f you tell me this is for sure only when you press |
Even if it's valid behaviour, i think it shouldn't spam to nvim logs. |
I'll observe and try to remap. |
I don’t think this can be avoided, the message comes from an internal monitor in neovim and cannot be disabled. |
Nope, this code is executed with every command that uses the headless wrapper, say you’re running Basically every command that has This is what spawns the wrapper: Lines 702 to 722 in 57cc8d1 |
Let me know your findings, the more info you have the more we can potentially find a workaround for this issue. |
|
@kaiphat, I rebased the require("fzf-lua").setup({
debug_tracelog = "~/fzf-lua-trace.log",
-- rest of your config
})Note that:
The next time you can reproduce the freeze we can look in the trace log and see which lines of code are run right before the freeze. |
ibhagwan
added
bug
ibhagwan
changed the title
|
autocmd TermOpen * setlocal foldmethod=manualActually scrap that, I added that in the latest commit as a potential workaround as there's no downside to setting |
|
@kaiphat, there’s a good chance the latest commit 1df84a4 will solve your issue, I took a look in your dotfiles and you’re using wo.foldmethod = 'expr'
wo.foldexpr = 'nvim_treesitter#foldexpr()'Please update to the latest and lmk if this is resolved? |
|
You are unbelievable good:) Thank you, i'll try |
Ty for the kinds words @kaiphat, now let’s hope I’m right :) |
|
Following your comment in #1096 (comment) The freeze might also be triggered nvim-cmp, I wonder why is nvim-cmp running inside the fzf buffer? |
|
I don’t think this is a cmp bug but this confirm it’s the same upstream issue, the lines of code from your debug log point to the same If you read my original post in neovim/neovim#20726 you can see similar trace log and the code looping the I can look into ways of running I will look into it nonetheless but your findings confirm the same upstream issue. |
|
@kaiphat, I got the idea from your logs to hook the require("fzf-lua").setup({
debug_tracelog = "~/fzf-lua-trace.log",
nvim_freeze_workaround = true,
})Enabling this will simply print the pressed key to the Lines 215 to 222 in d6b42bb If you can get it to freeze and our Once you get it to freeze, see if the timestamp in the messages (under the cmd line) progresses and also if the debug trace log shows fzf-lua (instead of |
|
@kaiphat, scrap my last comment, I implemented the logic to kill the job if we're stuck in a loop, let's hope this can solve your problem until the upstream is fixed, all you need is the require("fzf-lua").setup({
nvim_freeze_workaround = true,
})For now this also logs the initial ctrl-c but if this works properly we'll remove that message, after pressing If the process fails to terminate and goes into a loop, we'll hopefully get to this part of the code that terminates the process and if we're lucky also end the loop without any reprucussions :-) Lines 224 to 231 in e77207c The message from line 227 wll be printed to In my testing I managed to get to that part and it suceeded :-) |
|
Is it |
Yes |
|
@kaiphat, latest commit 25da40e added an option to control the verbosity level of the require("fzf-lua").setup({
-- 0: silent mode, no messages will be displayed
-- 1: display the message only if process kill workaround is applied
-- 2|true, display all `ctrl-c` keypresses (on normal fzf-lua UI close)
-- I'm using `1` for testing so I can see the message only if proccess was required to be killed
nvim_freeze_workaround = 1,
}) |
|
I found out that killing the process isn't getting neovim out of the loop as the issue is deeper inside neovim, it seems that raising a lua error does interrupt the lua execution, I guess it's preferable to have an annoying error than a freeze, I can live with that if this turns out to be the solution until the upstream is fixed. Update to af2c0fa (on |
|
I've came back:) There were a lot of problems) I checkouted to |
|
Also i noticed, that sometimes when i open fzf popup i am in normal mode. And if i do resume after that i see something like this. |
|
I don’t think the workaround in this thread will work, after debugging neovim with gdb, the issue is deeper, something appears to happen (my guess is the broke pipe signal to the term) that causes neovim to never clear the SIGINT and therefore it keeps thinking it received ctrl-c, not much I can do from fzf-lua’s end until the upstream is fixed. |
|
I completely changed mind and currently use |
Neovim often totally stucks when i use fzf-lua. How i can debug it and find a reason?
The text was updated successfully, but these errors were encountered: