neovim hang at 100% CPU when interrupted with <C-c> #20726

ibhagwan · 2022-10-18T20:40:23Z

Neovim version (nvim -v)

NVIM v0.8.0

Vim (not Nvim) behaves the same?

not using vim

Operating system/version

Void Linux kernel 5.10.147

Terminal name/version

alacritty 0.10.1

$TERM environment variable

screen-256color

Installation

Void Linux xbps package manager

How to reproduce the issue

I am able to consistently get neovim to hang at 100% CPU when using fzf-lua, opening any interface and quickly pressing <C-c>.

Note that to rerproduce this consistently this commit which maps <C-c> to <Esc> in termal mode, needs to be reverted or you can test with the trace branch which also contains trace logging to file.

What happens behind the scenes is fzf-lua opening a new window and running termopen with the fzf command and then waits for the job's on_exit callback.

While stuck I ran strace -s 99 -ffp <pid> on the neovim pid and it seems to be polling a no longer existing thread (not sure about that, but in the below pid 27433 no longer exists), the loop below continues endlessly:

[pid 27433] <... epoll_wait resumed>[{events=EPOLLIN, data={u32=18, u64=18}}], 1024, -1) = 1
[pid 27432] <... write resumed>)        = 8
[pid 27433] read(18, "\1\0\0\0\0\0\0\0", 1024) = 8
[pid 27432] epoll_wait(9,  <unfinished ...>
[pid 27433] epoll_wait(15,  <unfinished ...>
[pid 27432] <... epoll_wait resumed>[], 1024, 0) = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] write(32, "\3", 1)          = 1
[pid 27432] write(18, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>
[pid 27433] <... epoll_wait resumed>[{events=EPOLLIN, data={u32=18, u64=18}}], 1024, -1) = 1
[pid 27432] <... write resumed>)        = 8
[pid 27433] read(18, "\1\0\0\0\0\0\0\0", 1024) = 8
[pid 27432] epoll_wait(9,  <unfinished ...>
[pid 27433] epoll_wait(15,  <unfinished ...>
[pid 27432] <... epoll_wait resumed>[], 1024, 0) = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] epoll_wait(9, [], 1024, 0)  = 0
[pid 27432] write(32, "\3", 1)          = 1
[pid 27432] write(18, "\1\0\0\0\0\0\0\0", 8 <unfinished ...>

In an effort to understand where this issue comes from I added trace logging to my plugin from the moment the termopen succeeds until on_exit is called, you can enable logging to file (only with the trace branch) with:

require'fzf-lua'.setup({ debug_tracelog = "~/neovim.log" })

With the above setup the file gets overwritten each time the fzf-lua interface is open, the results indicate neovim is stuck in an endless loop calling the vim._on_key(char) function within the runtime runtime/lua/vim/_editor.lua:560, relevant part of the log right before it gets stuck:

2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:102 nil
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:79 finish
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:81 finish
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:82 finish
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:83 finish
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:85 finish
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/fzf-lua/lua/fzf-lua/fzf.lua:104 nil
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/gitsigns.nvim/lua/gitsigns/manager.lua:449 nil
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/gitsigns.nvim/lua/gitsigns/manager.lua:450 nil
2022-10-18T13:26:32 @/home/bhagwan/.local/share/nvim/site/pack/packer/opt/gitsigns.nvim/lua/gitsigns/manager.lua:451 nil
2022-10-18T13:26:32 @/usr/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:258 nil
2022-10-18T13:26:32 @/usr/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:259 nil
2022-10-18T13:26:32 @/usr/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:260 nil
2022-10-18T13:26:32 @vim/_editor.lua:561 nil  <= first line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:562 nil
2022-10-18T13:26:32 @vim/_editor.lua:563 nil
2022-10-18T13:26:32 @vim/_editor.lua:572 nil
2022-10-18T13:26:32 @vim/_editor.lua:581 nil
2022-10-18T13:26:32 @vim/_editor.lua:561 nil  <= first line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:562 nil  <= last line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:563 nil
2022-10-18T13:26:32 @vim/_editor.lua:572 nil
2022-10-18T13:26:32 @vim/_editor.lua:581 nil  <= last line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:561 nil  <= first line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:562 nil
2022-10-18T13:26:32 @vim/_editor.lua:563 nil
2022-10-18T13:26:32 @vim/_editor.lua:572 nil
2022-10-18T13:26:32 @vim/_editor.lua:581 nil  <= last line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:561 nil  <= first line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:562 nil
2022-10-18T13:26:32 @vim/_editor.lua:563 nil
2022-10-18T13:26:32 @vim/_editor.lua:572 nil
2022-10-18T13:26:32 @vim/_editor.lua:581 nil  <= last line of vim._on_key
2022-10-18T13:26:32 @vim/_editor.lua:561 nil  <= first line of vim._on_key

I think this might be related to neovim not yet interrupting lua code as explained in #6800?

@famiu, @ZyX-I, @justinmk, if my analysis is correct, do you have any idea why this happens? What part of the code causes this? Any workarounds I can apply before #19096 is merged (aside from remapping <C-c>)?

Expected behavior

Neovim should be able to handle <C-c>.

Actual behavior

Neovim will occasionally become unresponsive when pressing <C-c>.

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

vhoyer · 2022-10-21T17:44:21Z

vim-airline/vim-airline#2588 I can reproduce this freezing behavior with vim-airline

here is a reproduction repo: https://github.com/vhoyer-bug-reproductions/airline-freeze-on-C-c

vhoyer · 2022-10-21T17:45:49Z

also this is happening with NVIM v0.7.2

vhoyer · 2022-10-24T14:28:19Z

btw, vim-airline doesn't use lua, so I don't know if the labels are correctly applied, or maybe it's a different problem with the same behavior, should I open a new issue?

jrahm · 2023-01-30T20:40:40Z

Not sure if this is the same bug or not, but it sounds similar, and I believe I found fairly minimal steps to reproduce:

Open neovim with nvim -u NONE
Open a terminal
Source a file with the following contents:

local vim = assert(vim)
local loop = vim.loop

local i = 0

local function do_cmd()
  i = i + 1
  print ("spawn: " .. i)
  loop.spawn('echo', {
    args = {'hi'}
  }, function () end)
end

local function start_polling()
  vim.defer_fn(function ()
    local j = 0
    while j < 100 do
      do_cmd()
      j = j + 1
    end
    start_polling()
  end, 100)
end

start_polling()

In the terminal (in INSERT mode) hold Ctrl-C. (In otherwords just send a bunch of Ctrl-C's to the terminal. For reference I have my keyboard rate set to xset r rate 300 100, so it repeats pretty fast).

After several seconds the terminal should hang and Neovim will lock up at 100% CPU.

Obviously this example is pretty contrived, but the freeze happens often enough on my dev workflow to be annoying. (I have a plugin that periodically polls information by launching a bunch of commands). It appears to be a race conditions where if Ctrl-C is pressed at the exact wrong time during the job life cycle, it get's stuck in a loop.

Poking around in GDB indicates that Neovim thinks it's getting a constant stream of Ctrl-C's, so it appears that maybe got_int is not being cleared somewhere. Using gdb to manually set got_int = 0 will break the loop.

To further add to the mystery, I replicated this on 3 different machines (All Linux-based, Arch and Debian), however, I could not get the bug to replicate on a Gentoo server I run. All versions of Neovim were built from source though, so it seems strange to have different behavior. Maybe the server hardware is beefy enough that it masks the issue.

I was also able to replicate this issue on the packaged release of Neovim in Arch linux:

$ /usr/bin/nvim --version

NVIM v0.8.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by builduser

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

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

Run :checkhealth for more info

justinmk · 2023-06-04T01:08:39Z

We have clear repro steps given above. So I've hidden redundant comments (though the hints are appreciated).

Hippo0o · 2023-09-21T13:16:13Z

i was able to not trigger this bug every day by adding this in my alacritty config:

key_bindings:
  - { key: C, mods: Control,      mode: Alt,  action: None  } # fix neovim freezes
  - { key: C, mods: Alt|Control,  mode: ~Alt, chars: "\x03" }

it basically disables C-c in every tui and maps C-A-c to C-c instead.

mattpallissard · 2023-10-11T21:08:00Z

I've had the issue of ^c intermittently hosing terminal mode when a command writes a lot of data to std{out,err}.

:split +term
~  base64 < /dev/urandom
^c

While debugging this I noticed the following the logs

line 1: ^Ireturn luaeval(printf('require"nvim-treesitter.fold".get_fold_indic(%d)', v:lnum))
nvim_treesitter#foldexpr returning #0

calling nvim_treesitter#foldexpr()

I had the following settings.

set foldmethod=expr
set foldexpr=nvim_treesitter#foldexpr()

So I added this autocmd as a workaround.

autocmd TermOpen * set foldexpr&

This smells like a race condition that is exacerbated by the foldmethod, but I haven't been able to reproduce since modifying the foldexpr.

mattpallissard · 2023-10-11T21:12:19Z

Poking around in GDB indicates that Neovim thinks it's getting a constant stream of Ctrl-C's, so it appears that maybe got_int is not being cleared somewhere. Using gdb to manually set got_int = 0 will break the loop.

I'll also point out that I saw the same thing as @jrahm listed above. I spent a while stepping through with GDB before I stumbled upon the workaround in my previous comment.

wookayin · 2023-10-12T02:54:17Z

@mattpallissard That's a great finding! I can also confirm that setting foldexpr=0 for the terminal window prevents neovim from freezing, very consistently. A great repro. I also used the cat /dev/urandom | base64 example to flood terminal outputs.

In your workaround you globally set foldexpr&, but it'd be even better if one can set this locally to the terminal windows: setlocal foldexpr& or setlocal foldexpr=0 so that foldexpr can work for other buffers. Or simply setlocal foldmethod=manual (for the terminal buffer) also works by disabling the execution of foldexpr, hence another workaround:

  autocmd TermOpen * setlocal foldmethod=manual

I've made a more refined and clean version of the repro with minimal dependencies based on @mattpallissard's observation:

-- Run with: nvim --clean -u repro.lua, and hit <Ctrl-C>
vim.o.foldmethod = 'expr'
vim.o.foldexpr = 'MyFold()'

vim.cmd [[
  function! MyFold() abort
    " Do some expensive(?) computation inside foldexpr, to increase the chance of neovim freezing
    " Note: this function gets called **VERY OFTEN**, every single time terminal draws with a new character
    let i = 0 | while i <= 20 | let i += 1 | endwhile
    return 0
  endfunction
]]

vim.cmd [[ term base64 < /dev/urandom ]]
-- vim.cmd [[ setlocal foldmethod=manual ]] -- a workaround to prevent hanging (#20726)
vim.cmd [[ startinsert ]]

Some additional notes regarding the above repro

The following (lua function instead of vimscript foldexpr function) doesn't result in hanging. So it's probably related to vimscript execution?

vim.o.foldexpr = 'v:lua.MyFold()'
function _G.MyFold() return 0 end

The infinite loop happens here

With this repro and a bit of playing around with gdb, I also found that the infinite loop happens around:

safe_vgetc() which always returns 3 (CTRL-C) (due to got_int, as already pointed out in the above comments), and
s->execute(s, key) (i.e., terminal_execute) always return 1 (FAIL).

mattpallissard · 2023-10-12T04:01:16Z

I don't know the codebase well, but it seems like there are likely two problems

There is a context switch, from terminal to foldexpr, where an interrupt handler does the wrong thing.
The infinite loop after the interrupt is handled incorrectly.

Neovim often freezes when hitting `<Ctrl-C>` on a terminal. As a workaround for this bug, we disable folding (evaluation of `&foldexpr`) on terminal buffers because we don't really need folding in a terminal. See neovim/neovim#20726

justinmk · 2023-10-12T13:24:16Z

While debugging this I noticed the following the logs
line 1: ^Ireturn luaeval(printf('require"nvim-treesitter.fold".get_fold_indic(%d)', v:lnum))

Related?

Lua: interrupt / cancel Lua code #6800
Neovim hangs when an open buffer is modified externally and foldexpr is enabled. #25608
- but this is specifically about vim.treesitter.foldexpr, not the nvim-treesitter foldexpr.

chanha-park · 2023-11-28T05:55:59Z

I'm not sure if it's related or not, but I also have a foldexpr related issue. When I use a command like yes inside the nvim's built-in terminal, nvim just stucks.

After executing yes command, I cannot do anything.(none of <ESC>, <C-c>, <C-\>, <C-\><C-n> works)

Tested with minimal.lua below, with nvim --clean -u minimal.lua. Nvim version 0.9.4 on Linux Mint 21.

-- minimal.lua
for name, url in pairs({
    -- ADD PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE, e.g:
    -- some_plugin = 'https://github.com/author/plugin.nvim'
    ['nvim-treesitter'] = 'https://github.com/nvim-treesitter/nvim-treesitter',
}) do
    local install_path = vim.fn.fnamemodify('nvim_issue/' .. name, ':p')
    if vim.fn.isdirectory(install_path) == 0 then
        vim.fn.system({ 'git', 'clone', '--depth=1', url, install_path, })
    end
    vim.opt.runtimepath:append(install_path)
end

vim.opt.foldmethod = 'expr'
vim.opt.foldexpr = 'nvim_treesitter#foldexpr()'

There's an open issue where there appears to be race conditions when hitting Ctrl-C during lua deferred functions. Lots of people were hitting this when using treesitter folding in terminals. I was using indent, which may or may not have a similar problem, but either way I'm happy to disable folding in terminal. References: - issue: neovim/neovim#20726 - workaround: neovim/neovim#20726 (comment)

ibhagwan · 2024-04-01T06:02:33Z

May or may not be related, while attempting to debug this issue I've been using fzf-lua and spamming FzfLua + <C-c>, done enough times I would sometimes be able to hang neovim. However, doing so with gdb attached I am unable to get to the got_int loop described by both @jrahm in #20726 (comment) and @wookayin in #20726 (comment) but I do see the below in the gdb console every single time I am able to hang neovim:

Few examples below, each depicting a would-be got_int hang?

Thread 1 "nvim" received signal SIGPIPE, Broken pipe.
0x00007fa66ba9d60f in __GI___libc_write (nbytes=4093, buf=0x557165339f40, fd=20) at ../sysdeps/unix/sysv/linux/write.c:26
26	in ../sysdeps/unix/sysv/linux/write.c

Thread 1 "nvim" received signal SIGPIPE, Broken pipe.
0x00007fa66ba9d60f in __GI___libc_write (nbytes=2174, buf=0x55716533af50, fd=20) at ../sysdeps/unix/sysv/linux/write.c:26
26	in ../sysdeps/unix/sysv/linux/write.c

Thread 1 "nvim" received signal SIGPIPE, Broken pipe.
0x00007fa66ba9d60f in __GI___libc_write (nbytes=164, buf=0x5571654bcf40, fd=21) at ../sysdeps/unix/sysv/linux/write.c:26
26	in ../sysdeps/unix/sysv/linux/write.c

Is it possible that somehow the combination of receing the SIGPIPE causes got_int to never get cleared and thus enter the infinite loop?

@justinmk, is it possible this issue is not related to lua code interruption or folds?

ibhagwan added the bug issues reporting wrong behavior label Oct 18, 2022

zeertzjq added job-control OS processes, spawn input lua stdlib and removed job-control OS processes, spawn labels Oct 18, 2022

chrisbra mentioned this issue Oct 19, 2022

nvim freezes when <C-c> on a terminal buffer vim-airline/vim-airline#2588

Closed

zeertzjq added job-control OS processes, spawn terminal built-in :terminal or :shell and removed lua stdlib labels Oct 24, 2022

ibhagwan mentioned this issue Feb 17, 2023

please do tnoremap <C-c> <Esc> ibhagwan/fzf-lua#653

Closed

neovim deleted a comment from masaeedu Mar 12, 2023

neovim deleted a comment from vhoyer Mar 12, 2023

neovim deleted a comment from masaeedu Mar 12, 2023

This comment was marked as duplicate.

Sign in to view

This comment was marked as off-topic.

Sign in to view

ibhagwan mentioned this issue Sep 25, 2023

Deadlock and neovim hangs forever when fzf command fails ibhagwan/fzf-lua#886

Closed

ibhagwan mentioned this issue Oct 13, 2023

Performance regarding closing the fzf-lua window compared to fzf.vim ibhagwan/fzf-lua#904

Closed

1 task

ibhagwan mentioned this issue Nov 6, 2023

FzfLua Intermittently Hangs and Crashes Neovim ibhagwan/fzf-lua#922

Closed

1 task

amaanq mentioned this issue Feb 19, 2024

Neovim freezes when using zig treesitter. nvim-treesitter/nvim-treesitter#6134

Closed

ibhagwan mentioned this issue Mar 19, 2024

Neovim occasional hang/freeze when using ctrl-c to exit fzf-lua ibhagwan/fzf-lua#1091

Open

ibhagwan mentioned this issue Mar 31, 2024

[lldb-vscode] Breakpoint unverified in nvim-dap but resolved accurately in lldb cli? mfussenegger/nvim-dap#1184

Closed

TheLeoP added a commit to TheLeoP/nvim-config that referenced this issue Apr 23, 2024

Disable fold inside of terminal because of neovim/neovim#20726

ccbb20c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

neovim hang at 100% CPU when interrupted with <C-c> #20726

neovim hang at 100% CPU when interrupted with <C-c> #20726

ibhagwan commented Oct 18, 2022 •

edited

vhoyer commented Oct 21, 2022

vhoyer commented Oct 21, 2022

vhoyer commented Oct 24, 2022

jrahm commented Jan 30, 2023 •

edited

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

justinmk commented Jun 4, 2023

This comment was marked as off-topic.

Hippo0o commented Sep 21, 2023 •

edited

mattpallissard commented Oct 11, 2023 •

edited

mattpallissard commented Oct 11, 2023

wookayin commented Oct 12, 2023 •

edited

mattpallissard commented Oct 12, 2023

justinmk commented Oct 12, 2023 •

edited

chanha-park commented Nov 28, 2023

ibhagwan commented Apr 1, 2024 •

edited

neovim hang at 100% CPU when interrupted with <C-c> #20726

neovim hang at 100% CPU when interrupted with <C-c> #20726

Comments

ibhagwan commented Oct 18, 2022 • edited

Neovim version (nvim -v)

Vim (not Nvim) behaves the same?

Operating system/version

Terminal name/version

$TERM environment variable

Installation

How to reproduce the issue

Expected behavior

Actual behavior

vhoyer commented Oct 21, 2022

vhoyer commented Oct 21, 2022

vhoyer commented Oct 24, 2022

jrahm commented Jan 30, 2023 • edited

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

justinmk commented Jun 4, 2023

This comment was marked as off-topic.

Hippo0o commented Sep 21, 2023 • edited

mattpallissard commented Oct 11, 2023 • edited

mattpallissard commented Oct 11, 2023

wookayin commented Oct 12, 2023 • edited

mattpallissard commented Oct 12, 2023

justinmk commented Oct 12, 2023 • edited

chanha-park commented Nov 28, 2023

ibhagwan commented Apr 1, 2024 • edited

ibhagwan commented Oct 18, 2022 •

edited

jrahm commented Jan 30, 2023 •

edited

Hippo0o commented Sep 21, 2023 •

edited

mattpallissard commented Oct 11, 2023 •

edited

wookayin commented Oct 12, 2023 •

edited

justinmk commented Oct 12, 2023 •

edited

ibhagwan commented Apr 1, 2024 •

edited