ms-jpq / coq_nvim

Fast as FUCK nvim completion. SQLite, concurrent scheduler, hundreds of hours of optimization.
GNU General Public License v3.0
3.56k stars 100 forks source link

Neovim 0.5.0 Crashes with Segmentation Fault (Core Dumped) when Accepting Completions while Editing Commit Message with Fugitive #265

Open gkapfham opened 3 years ago

gkapfham commented 3 years ago

Hello! Thanks for creating the coq_nvim plugin! I have really appreciated how easy it is to get it up and running and the speed with which is suggests the completions. It is also impressive how it works so well with the LSPs that I have setup for different languages! In summary, I'm really thankful for this plugin and I hope that you continue to improve it!

When I started using this plugin I initially found it to be very stable. However, recently I find that when I accept at least one completion accepted by coq_nvim when I am editing a commit message in Neovim using Fugitive then Neovim crashes with a segmentation fault (core dumped) message. What I have found is that Neovim never crashes in the same situation if I do not accept one of the completions suggested by coq_nvim. However, as soon as I accept at least one completion there is at least a 30% chance that I receive one of the following messages after Neovim crashes:

After extensive experimentation I regret that I cannot better explain the failure condition than what I have provided in the previous paragraph. To be clear, I have not yet invested enough time to absolutely localize the problem to the coq_nvim plugin — it could be something else in my configuration and I've not yet done enough delta debugging to confirm that it is definitely related to the acceptance of a completion suggested by coq_nvim. With that said, I thought it might be helpful if I raised the issue now so that we could at least briefly discuss this potential problem and then decide on a way forward. I have also searched this project's issue tracker and I did not see any reports of this problem.

Here are some additional details about the configuration on my computer:

Operating System:

Linux 5.13.13-arch1-1 #1 SMP PREEMPT Thu, 26 Aug 2021 19:14:36 +0000 x86_64 GNU/Linux

Neovim Version:

NVIM v0.5.0
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -DNDEBUG -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/build/neovim/src/neovim-0.5.0/build/config -I/build/neovim/src/neovim-0.5.0/src -I/usr/include -I/build/neovim/src/neovim-0.5.0/build/src/nvim/auto -I/build/neovim/src/neovim-0.5.0/build/include
Compiled by builduser

Git Version:

git version 2.33.0

I am also running Neovim inside of a tmux session. Here are the details about tmux:

tmux 3.2a

Python Version:

Python 3.9.2

It is also worth noting that I install and use Python through pyenv. I'm not sure which version of Python your plugin picks up automatically, by this is the one that I am currently using:

/home/gkapfham/.pyenv/shims/python

I configure Python inside of Neovim with the following source code:

let g:python_host_prog  = '/usr/bin/python2'
if filereadable('/usr/local/bin/python3')
  let g:python3_host_prog = '/usr/local/bin/python3'
else
  let g:python3_host_prog = '/usr/bin/python'
endif

I am currently running tmux and Neovim inside of zsh. Here is the configuration:

zsh 5.8 (x86_64-pc-linux-gnu)

Here is my minimal configuration of this plugin:

let g:coq_settings = {"display.pum.source_context" : ["  ", " "], "display.pum.kind_context" : [" ", " "], 'auto_start': 'shut-up'}

I am currently using vim-plug to install the plugin with:

Plug 'ms-jpq/coq_nvim', {'branch': 'coq'}
Plug 'ms-jpq/coq.artifacts', {'branch': 'artifacts'}

I have tried several different configurations of coq_nvim and I can't find one that avoids the segmentation fault. With that said, it is worth noting that coq_nvim never causes a segmentation fault unless I am editing a commit message. That is, the plugin always works flawlessly when I edit course code and accept completions in any type of buffer except for a Fugitive or Neogit buffer that enables me to edit the commit message. I can also confirm that I always run the COQdeps command whenever the coq_nvim plugin requests that I do so. To date, I've never seen that process crash or repot any errors after the dependency update process.

Here is an example of a screen shot where I am editing file.txt by placing "lorem ipsum" text inside of it and then using Fugitive to write a commit message. After coq_nvim suggests some completions I pick them, normally using words like "consetetur" and "eirmod" and "nonumy". After I attempt to save the commit message with Fugitive I receive the segmentation fault error. I can confirm that this happens with files written in JavaScript, Python, Markdown, and Vim configuration. It seems unlikely that the problem is specifically connected to Fugitive because the same segmentation faults occur with I edit a commit message with Neogit. Finally, I don't have any evidence that the problem is with Neovim itself because if I disable coq_nvim or I don't accept its suggested completions then I never have a segmentation fault and a crash of Neovim.

image

Thanks for taking the time to read this issue! Is there any other information that you would like me to provide so that I can best support the debugging of this problem? I would be glad to help as best as I can so that we can work together to determine if the problem is, in fact, related to coq_nvim and the accepting of completions inside of the Fugitive or Neogit buffers.

In summary, it would be awesome if you could point me in the right direction to further debugging this issue. If you think that this might be a problem in coq_nvim, it would be great if you could resolve it in a forthcoming version of coq_nvim. If you don't think that the problem is in coq_nvim then any ideas that you can share would also be very greatly appreciated! Thanks!

smjonas commented 3 years ago

Possibly related: I also had these Neovim crashes lately which I never had before. For me they sometimes happen when resizing the Neovim application window. Since I have not updated Neovim since 0.5 stable, this very likely has to do with some plugin, although I am not sure which one yet. I will try to reproduce the crash more reliably. @gkapfham is there a way I can see the exact Neovim error like segmentation fault etc.? Is there some file that logs these errors?

gkapfham commented 3 years ago

Hello @jonasstr thanks for your feedback!

I ran Neovim in a fashion that would extract a stacktrace, following this tutorial:

https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-stacktrace-when-my-program-crashes

This produced the following stack trace:

7f23875cf000-7f23875d0000 r-xp 00000000 00:00 0
7f23875d0000-7f23875d3000 r--p 00000000 fe:02 1183184 /usr/lib/libnss_files-2.33.so
7f23875d3000-7f23875da000 r-xp 00003000 fe:02 1183184 /usr/lib/libnss_files-2.33.so
7f23875da000-7f23875dc000 r--p 0000a000 fe:02 1183184 /usr/lib/libnss_files-2.33.so
7f23875dc000-7f23875dd000 r--p 0000b000 fe:02 1183184 /usr/lib/libnss_files-2.33.so
7f23875dd000-7f23875de000 rw-p 0000c000 fe:02 1183184 /usr/lib/libnss_files-2.33.so
7f23875de000-7f23875e4000 rw-p 00000000 00:00 0
7f23875e4000-7f23875e5000 r--p 00000000 fe:03 1319589 /home/gkapfham/.vim/bundle/telescope-fzf-native.nvim/build/libfzf.so
7f23875e5000-7f23875e9000 r-xp 00001000 fe:03 1319589 /home/gkapfham/.vim/bundle/telescope-fzf-native.nvim/build/libfzf.so
7f23875e9000-7f23875ea000 r--p 00005000 fe:03 1319589 /home/gkapfham/.vim/bundle/telescope-fzf-native.nvim/build/libfzf.so
7f23875ea000-7f23875eb000 r--p 00005000 fe:03 1319589 /home/gkapfham/.vim/bundle/telescope-fzf-native.nvim/build/libfzf.so
7f23875eb000-7f23875ec000 rw-p 00006000 fe:03 1319589 /home/gkapfham/.vim/bundle/telescope-fzf-native.nvim/build/libfzf.so
7f23875ec000-7f23875ed000 r--p 00000000 fe:02 1183099 /usr/lib/libSegFault.so
7f23875ed000-7f23875f0000 r-xp 00001000 fe:02 1183099 /usr/lib/libSegFault.so
7f23875f0000-7f23875f1000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f23875f1000-7f23875f2000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f23875f2000-7f23875f3000 rw-p 00005000 fe:02 1183099 /usr/lib/libSegFault.so
7f23875f3000-7f23875f5000 rw-p 00000000 00:00 0
7f23875f5000-7f23875f6000 r--p 00000000 fe:02 1183082 /usr/lib/ld-2.33.so
7f23875f6000-7f238761a000 r-xp 00001000 fe:02 1183082 /usr/lib/ld-2.33.so
7f238761a000-7f2387623000 r--p 00025000 fe:02 1183082 /usr/lib/ld-2.33.so
7f2387623000-7f2387625000 r--p 0002d000 fe:02 1183082 /usr/lib/ld-2.33.so
7f2387625000-7f2387627000 rw-p 0002f000 fe:02 1183082 /usr/lib/ld-2.33.so
7f23b1410000-7f23b1420000 r-xp 00000000 00:00 0
7ffe668a5000-7ffe668c7000 rw-p 00000000 00:00 0 [stack]
7ffe66906000-7ffe6690a000 r--p 00000000 00:00 0 [vvar]
7ffe6690a000-7ffe6690c000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]

This suggested that the problem was with the use of the fzf-native plugin that I use with Telescope. I removed that plugin and then I ran tests like I had before and I could confirm that the segmentation fault was still evident. Here is the specific stacktrace I saw when running Neovim without fzf-native inside of Telescope:

1216595 /usr/lib/libmsgpackc.so.2.0.0
7f5bfdf18000-7f5bfdf19000 rw-p 00008000 fe:02 1216595 /usr/lib/libmsgpackc.so.2.0.0
7f5bfdf19000-7f5bfdf21000 r--p 00000000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf21000-7f5bfdf3c000 r-xp 00008000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf3c000-7f5bfdf46000 r--p 00023000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf46000-7f5bfdf47000 ---p 0002d000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf47000-7f5bfdf48000 r--p 0002d000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf48000-7f5bfdf49000 rw-p 0002e000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f5bfdf49000-7f5bfdf52000 r--p 00000000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f5bfdf52000-7f5bfdf6a000 r-xp 00009000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f5bfdf6a000-7f5bfdf72000 r--p 00021000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f5bfdf72000-7f5bfdf75000 r--p 00028000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f5bfdf75000-7f5bfdf76000 rw-p 0002b000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f5bfdf93000-7f5bfdf94000 r-xp 00000000 00:00 0
7f5bfdf94000-7f5bfdf95000 r--p 00000000 fe:02 1183099 /usr/lib/libSegFault.so
7f5bfdf95000-7f5bfdf98000 r-xp 00001000 fe:02 1183099 /usr/lib/libSegFault.so
7f5bfdf98000-7f5bfdf99000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f5bfdf99000-7f5bfdf9a000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f5bfdf9a000-7f5bfdf9b000 rw-p 00005000 fe:02 1183099 /usr/lib/libSegFault.so
7f5bfdf9b000-7f5bfdf9d000 rw-p 00000000 00:00 0
7f5bfdf9d000-7f5bfdf9e000 r--p 00000000 fe:02 1183082 /usr/lib/ld-2.33.so
7f5bfdf9e000-7f5bfdfc2000 r-xp 00001000 fe:02 1183082 /usr/lib/ld-2.33.so
7f5bfdfc2000-7f5bfdfcb000 r--p 00025000 fe:02 1183082 /usr/lib/ld-2.33.so
7f5bfdfcb000-7f5bfdfcd000 r--p 0002d000 fe:02 1183082 /usr/lib/ld-2.33.so
7f5bfdfcd000-7f5bfdfcf000 rw-p 0002f000 fe:02 1183082 /usr/lib/ld-2.33.so
7f5c27db0000-7f5c27dc0000 r-xp 00000000 00:00 0
7ffd6928c000-7ffd692af000 rw-p 00000000 00:00 0 [stack]
7ffd69355000-7ffd69359000 r--p 00000000 00:00 0 [vvar]
7ffd69359000-7ffd6935b000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]

I think that the crash after the removal of fzf-native for Telescope and the second stack trace suggests that the problem is not related to that plugin, right? @ms-jpq and @jonasstr do these stack traces help you to debug the problem?

For what it is worth, here are the plugins that I use in Neovim:

Plug 'airblade/vim-rooter'
Plug 'andymass/vim-matchup'
Plug 'bkad/CamelCaseMotion'
Plug 'bronson/vim-visual-star-search'
Plug 'cespare/vim-toml'
Plug 'chrisbra/csv.vim', {'for': 'csv'}
Plug 'ColinKennedy/vim-textobj-block-party'
Plug 'fhill2/telescope-ultisnips.nvim'
Plug 'folke/which-key.nvim'
Plug 'garbas/vim-snipmate'
Plug 'ggandor/lightspeed.nvim'
Plug 'gkapfham/vim-vitamin-onec'
Plug 'honza/vim-snippets'
Plug 'iamcco/markdown-preview.nvim', {'do': { -> mkdp#util#install() }, 'for': 'markdown'}
Plug 'itchyny/lightline.vim'
Plug 'jalvesaq/Nvim-R', {'for': 'r'}
Plug 'janko-m/vim-test', {'for': 'python'}
Plug 'jgdavey/tslime.vim'
Plug 'junegunn/fzf', {'dir': '~/.fzf', 'do': './install --all'}
Plug 'junegunn/fzf.vim'
Plug 'junegunn/vim-easy-align'
Plug 'justinmk/vim-dirvish'
Plug 'kana/vim-textobj-user'
Plug 'KeitaNakamura/highlighter.nvim', {'do': ':UpdateRemotePlugins'}
Plug 'KeitaNakamura/tex-conceal.vim', {'for': 'tex'}
Plug 'kevinhwang91/nvim-bqf', {'branch': 'main'}
Plug 'Konfekt/vim-sentence-chopper'
Plug 'kristijanhusak/vim-dirvish-git'
Plug 'kshenoy/vim-signature'
Plug 'lervag/lists.vim'
Plug 'lervag/vimtex', {'for': 'tex'}
Plug 'lervag/wiki.vim'
Plug 'lewis6991/gitsigns.nvim'
Plug 'lifepillar/vim-colortemplate'
Plug 'ludovicchabant/vim-gutentags'
Plug 'machakann/vim-sandwich'
Plug 'machakann/vim-swap'
Plug 'MarcWeber/vim-addon-mw-utils'
Plug 'mgee/lightline-bufferline'
Plug 'mxw/vim-jsx', {'for': 'javascript.jsx'}
Plug 'neovim/nvim-lspconfig'
Plug 'norcalli/nvim-colorizer.lua'
Plug 'nvim-lua/plenary.nvim'
Plug 'nvim-lua/popup.nvim'
Plug 'nvim-telescope/telescope-fzf-native.nvim', {'do': 'make'}
Plug 'nvim-telescope/telescope-github.nvim'
Plug 'nvim-telescope/telescope.nvim'
Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}
Plug 'pangloss/vim-javascript', {'for': 'javascript.jsx'}
Plug 'pgdouyon/vim-evanesco'
Plug 'Pocco81/AutoSave.nvim'
Plug 'prabirshrestha/async.vim'
Plug 'Quramy/vim-js-pretty-template', {'for': 'javascript.jsx'}
Plug 'rhysd/git-messenger.vim'
Plug 'simnalamburt/vim-mundo', {'on': 'MundoToggle'}
Plug 'sindrets/diffview.nvim'
Plug 'SirVer/ultisnips'
Plug 'skywind3000/asyncrun.vim'
Plug 'tfnico/vim-gradle'
Plug 'TimUntersberger/neogit'
Plug 'tomtom/tlib_vim'
Plug 'tpope/vim-abolish'
Plug 'tpope/vim-commentary'
Plug 'tpope/vim-fugitive'
Plug 'tpope/vim-liquid'
Plug 'tpope/vim-repeat'
Plug 'tpope/vim-unimpaired'
Plug 'tweekmonster/braceless.vim'
Plug 'tweekmonster/spellrotate.vim'
Plug 'Valloric/ListToggle'
Plug 'Vimjas/vim-python-pep8-indent'
Plug 'vim-pandoc/vim-pandoc-syntax'
Plug 'vim-scripts/python_match.vim'
Plug 'vim-scripts/SyntaxAttr.vim'
Plug 'w0rp/ale'
Plug 'wellle/targets.vim'
Plug 'whatyouhide/vim-textobj-xmlattr', {'for': ['html', 'md', 'liquid']}
Plug 'williamboman/nvim-lsp-installer'
Plug 'xolox/vim-misc'
Plug 'ms-jpq/coq_nvim', {'branch': 'coq'}
Plug 'ms-jpq/coq.artifacts', {'branch': 'artifacts'}

Please let me know if there is any other information that I could provide in order to better help you understand the underlying cause of this segmentation fault! Thanks again for taking the time to read this update and investigate the issue further.

ms-jpq commented 3 years ago

Can you please disable treesitter?

its probably because it segfaulted, bad treesitter parsers can do that quite often

ms-jpq commented 3 years ago

please tell me how it goes! thanks!

ms-jpq commented 3 years ago

@jonasstr

treesitter is known to to crash nvim, maybe if you disable that it will help.

gkapfham commented 3 years ago

Hello @ms-jpq and @jonasstr! I completely disabled all of my Treesitter configurations and then continued in my normal workflow and I can confirm that Neovim crashes in exactly the same circumstance that I outlined in my initial report.

Here is an excerpt of a crash report generated by the catchsegv program:

7f8c1db3e000-7f8c1db3f000 r--p 00007000 fe:02 1216595 /usr/lib/libmsgpackc.so.2.0.0
7f8c1db3f000-7f8c1db40000 rw-p 00008000 fe:02 1216595 /usr/lib/libmsgpackc.so.2.0.0
7f8c1db40000-7f8c1db48000 r--p 00000000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db48000-7f8c1db63000 r-xp 00008000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db63000-7f8c1db6d000 r--p 00023000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db6d000-7f8c1db6e000 ---p 0002d000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db6e000-7f8c1db6f000 r--p 0002d000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db6f000-7f8c1db70000 rw-p 0002e000 fe:02 1241763 /usr/lib/libuv.so.1.0.0
7f8c1db70000-7f8c1db79000 r--p 00000000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f8c1db79000-7f8c1db91000 r-xp 00009000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f8c1db91000-7f8c1db99000 r--p 00021000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f8c1db99000-7f8c1db9c000 r--p 00028000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f8c1db9c000-7f8c1db9d000 rw-p 0002b000 fe:02 1216615 /usr/lib/libluv.so.1.41.0
7f8c1dbba000-7f8c1dbbb000 r-xp 00000000 00:00 0
7f8c1dbbb000-7f8c1dbbc000 r--p 00000000 fe:02 1183099 /usr/lib/libSegFault.so
7f8c1dbbc000-7f8c1dbbf000 r-xp 00001000 fe:02 1183099 /usr/lib/libSegFault.so
7f8c1dbbf000-7f8c1dbc0000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f8c1dbc0000-7f8c1dbc1000 r--p 00004000 fe:02 1183099 /usr/lib/libSegFault.so
7f8c1dbc1000-7f8c1dbc2000 rw-p 00005000 fe:02 1183099 /usr/lib/libSegFault.so
7f8c1dbc2000-7f8c1dbc4000 rw-p 00000000 00:00 0
7f8c1dbc4000-7f8c1dbc5000 r--p 00000000 fe:02 1183082 /usr/lib/ld-2.33.so
 7f8c1dbc5000-7f8c1dbe9000 r-xp 00001000 fe:02 1183082 /usr/lib/ld-2.33.so

While I acknowledge that it is possible that I've overlooked something when it comes to disabling Treesitter, I can confirm that I commented out all of the plugins and configurations in my runtime configuration file and the standard commands like TSBufEnable are no longer available. As such, this seems to suggest that there is still something, perhaps connect to coq_nvim, that causes segmentation faults at least 30% of the time when I accept a completion when writing a commit message with Fugitive. I should also point out that Neovim does not crash in any other situation when I am accepting completions — it only happens when I am editing a commit message and then attempt to save the buffer and perform the commit.

Thanks again for sharing the idea of disabling the Treesitter. Are there any other steps that I can take to assist you in debugging and fixing this issue? Thanks for all of your time and effort associated with both this plugin and the resolution of this issue!

gkapfham commented 3 years ago

Oh, @ms-jpq, there is one issue that I realized was not clear enough in my initial report!

The segmentation faults that I have described happen when:

To be clear, the segmentation fault does not occur immediately when I accept a completion from coq_nvim. Instead, it only happens when I save and then exit the buffer. The segmentation fault occurs the moment I save the buffer and the git commit does not take place. Okay, I hope that this better describes the exact situation in which the segmentation fault takes place!

ms-jpq commented 3 years ago

hey thank you so much for all the information its super helpful,

I just want you to know that I will be busy IRL for a while so I will apologize ahead of time, that I will not be able to look into this in depth for probably a week if im being totally honest.

ms-jpq commented 3 years ago

thank you so much though!

akaswenwilk commented 1 year ago

hey, I don't know if this is still an issue for you, but I experienced the same issue and it seems to have been fixed by upgrading to latest stable version of neovim (0.8.1). Hope this helps!