Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

halt on exit #178

Closed
meijieru opened this issue May 9, 2018 · 35 comments
Closed

halt on exit #178

meijieru opened this issue May 9, 2018 · 35 comments

Comments

@meijieru
Copy link

@meijieru meijieru commented May 9, 2018

If I open a file in the file system and quit quickly, neovim complains following and halt

Error detected while processing DirChanged Auto commands for "*":
E475: Invalid argument: Channel doesn't exist
E475: Invalid argument: Channel doesn't exist
Error detected while processing function <SNR>133_nvim_job_exit_wrapper[1]..gutentags#gtags_cscope#on_job_exit[3]..gutentags#remove_job:
line   22:
E171: Missing :endif

nvim --version generate

NVIM v0.3.0-dev
Build type: RelWithDebInfo
Lua 5.1
Compilation: /usr/bin/x86_64-linux-gnu-gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector --param ssp-buffer-size=4 -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-iMIrMh/neovim-0.2.2ubuntu2+git201805062018-ebb1acb-f2f288d/build/config -I/build/neovim-iMIrMh/neovim-0.2.2ubuntu2+git201805062018-ebb1acb-f2f288d/src -I/build/neovim-iMIrMh/neovim-0.2.2ubuntu2+git201805062018-ebb1acb-f2f288d/.deps/usr/include -I/usr/include -I/build/neovim-iMIrMh/neovim-0.2.2ubuntu2+git201805062018-ebb1acb-f2f288d/build/src/nvim/auto -I/build/neovim-iMIrMh/neovim-0.2.2ubuntu2+git201805062018-ebb1acb-f2f288d/build/include
Compiled by buildd@lgw01-amd64-016

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

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

Run :checkhealth for more info
@mellery451
Copy link

@mellery451 mellery451 commented May 9, 2018

I'm seeing the same thing when editing git commit messages, which tend to be short-lived temp files (I think)

@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Jun 9, 2018

Ah good to know -- I might have to add a default list of filetype values for which Gutentags should be disabled (right now it only checks buftype... which works for me since I'm mostly using Mercurial, with my Lawrencium Vim plugin, and that does set the buftype for commit messages/status buffers/etc. :) ).

There's a general issue in Neovim right now about exiting while tags generation is running -- see issue #167.

That said, it looks like there might be some other problem here caused by Gutentags and some other plugin interfering with each other. The error you mentioned seems to be raised through something running auto-commands on the DirChanged event, and that's not Gutentags. Do you have any idea what plugin that is, @meijieru ?

@meijieru
Copy link
Author

@meijieru meijieru commented Jun 11, 2018

How could I check the autocmd runned in the process? @ludovicchabant

@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Jun 11, 2018

You can type :autocmd DirChanged to see what functions have been registered... usually you'll spot some name of a plugin you recognize in there.

@meijieru
Copy link
Author

@meijieru meijieru commented Jun 13, 2018

output

--- Auto-Commands ---
DirChanged
    *         call rpcnotify(1, "python_chdir", v:event.cwd)
startify  DirChanged
    <buffer=1>
              Startify

maybe startify or neovim itself?

@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Jun 14, 2018

Maybe..... (I didn't know startify, thanks for that, it looks interesting :) )

You could try to disable startify... I don't know what that rpcnotify is though... is that Neovim itself? (I don't have it in my copy of Neovim, but I'm still on 0.2.2).

@meijieru
Copy link
Author

@meijieru meijieru commented Jun 14, 2018

Yeah, it used to notify python client that current dir has been changed, which included in neovim 0.3.0

@gkapfham
Copy link

@gkapfham gkapfham commented Jun 17, 2018

Hello @ludovicchabant, I am writing to confirm that I also experience this error, specifically seeing this message when I use Neovim to edit a commit message for Git:

Error detected while processing function deoplete#send_event[1]..deoplete#util#rpcnotify[2]..<SNR>20_notify:
line    9:
E475: Invalid argument: Channel doesn't exist
Error detected while processing DirChanged Auto commands for "*":
E475: Invalid argument: Channel doesn't exist
Error detected while processing function deoplete#send_event[1]..deoplete#util#rpcnotify[2]..<SNR>20_notify:
line    9:
E475: Invalid argument: Channel doesn't exist
Error detected while processing function <SNR>153_nvim_job_exit_wrapper[1]..gutentags#ctags#on_job_exit[1]..gutentags#remove_job_by_data[2]..gutentags#remove_job:

Here are the details about the version of Neovim:

NVIM v0.3.1-dev
Build type: RelWithDebInfo
Lua 5.1
Compilation: /usr/bin/x86_64-linux-gnu-gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-Ll32jb/neovim-0.2.2ubuntu2+git201806142018-c46997a-f2f288d/build/config -I/build/neovim-Ll32jb/neovim-0.2.2ubuntu2+git201806142018-c46997a-f2f288d/src -I/build/neovim-Ll32jb/neovim-0.2.2ubuntu2+git201806142018-c46997a-f2f288d/.deps/usr/include -I/usr/include -I/build/neovim-Ll32jb/neovim-0.2.2ubuntu2+git201806142018-c46997a-f2f288d/build/src/nvim/auto -I/build/neovim-Ll32jb/neovim-0.2.2ubuntu2+git201806142018-c46997a-f2f288d/build/include
Compiled by buildd@lcy01-amd64-016

I am running Neovim on an Ubuntu 16.04 machine. Is there a workaround that you would suggest?

@xiamaz
Copy link

@xiamaz xiamaz commented Oct 25, 2018

This issue still exists in the release version of neovim 0.3.1

@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Nov 12, 2018

I can't reproduce this bug with Neovim 0.3.1, but I just pushed commit 2689e11 which adds a new g:gutentags_exclude_filetypes options where you could add gitcommit or whatever is the file type of the temporary commit message file. That would prevent Gutentags from doing anything for that kind of buffer.

@stephendolan
Copy link

@stephendolan stephendolan commented Dec 4, 2018

@ludovicchabant ,

I'm still getting the error in the original issue description here, even though it seems from #167 that it should be resolved.

My :checkhealth in neovim v0.3.1 returns that everything is okay.

If I open a ruby file, then quickly :wq, I get the following:

Error detected while processing DirChanged Auto commands for "*":
E475: Invalid argument: Channel doesn't exist
E475: Invalid argument: Channel doesn't exist
Error detected while processing function <SNR>103_nvim_job_exit_wrapper[1]..gutentags#ctags#on_job_exit[1]..gutentags#remove_job_by_data[2]..gutentags#remove_job:
line   22:
E171: Missing :endif

Neovim version output:

NVIM v0.3.1
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/local/Homebrew/Library/Homebrew/shims/mac/super/clang -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20180820-47777-1t89t8z/neovim-0.3.1/build/config -I/tmp/neovim-20180820-47777-1t89t8z/neovim-0.3.1/src -I/usr/local/include -I/usr/local/opt/gettext/include -I/usr/include -I/tmp/neovim-20180820-47777-1t89t8z/neovim-0.3.1/build/src/nvim/auto -I/tmp/neovim-20180820-47777-1t89t8z/neovim-0.3.1/build/include
Compiled by brew@HighSierra.local

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

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

Run :checkhealth for more info

And the output of :autocmd DirChanged:

:autocmd DirChanged
--- Auto-Commands ---
DirChanged
    *         call rpcnotify(3, "python_chdir", v:event.cwd)
@megalithic
Copy link

@megalithic megalithic commented Dec 20, 2018

@stephendolan getting the same with elixir files. /cc @ludovicchabant

@ryanbas21
Copy link

@ryanbas21 ryanbas21 commented Jan 11, 2019

@ludovicchabant I get this error on exit also.

@dynofu
Copy link

@dynofu dynofu commented Mar 13, 2019

i use spacevim, this is the result of search DirChanged

[dynofu:~ … /vimfiles] $ rg -g "*.vim" DirChanged
repos/github.com/Shougo/deol.nvim/autoload/deol.vim
245:  if exists('##DirChanged') && g:deol#enable_dir_changed
247:      autocmd deol DirChanged <buffer>
250:      autocmd deol DirChanged <buffer>

repos/github.com/mhinz/vim-startify/autoload/startify.vim
133:  if exists('##DirChanged')
135:    autocmd startify DirChanged <buffer> if getcwd() !=# get(get(b:, 'startify', {}), 'cwd') | Startify | endif

repos/github.com/neoclide/coc.nvim/plugin/coc.vim
106:      autocmd DirChanged       * call s:Autocmd('DirChanged', expand('<afile>'))
108:      autocmd DirChanged       * call s:Autocmd('DirChanged', get(v:event, 'cwd', ''))
@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Mar 13, 2019

It looks like the common factor with all people having this bug is that they all have this rpcnotify as a DirChanged auto-command. I tried installing Deoplete and Startify but that didn't give me that callback... is there something specific I should do to get this rpcnotify thing?

@dynofu
Copy link

@dynofu dynofu commented Mar 13, 2019

rpcnotify looks like is about remote plugin and my :UpdateRemotePlugins shows

remote/host: python3 host registered plugins ['denite', 'semshi']
remote/host: generated rplugin manifest: /Users/dynofu/.local/share/nvim/rplugin.vim
@dynofu
Copy link

@dynofu dynofu commented Mar 14, 2019

vim x.py; ps -ef | grep tags edit a file then quit immediately and check tags process.
when the problem happens, before ps -ef got executed i still got chance to check the process activity and gtags is running then exit.

for what it worth with the detached jobstart option, there won't be the problem, but it won't kill the job process either (probably expected).

git diff
diff --git a/autoload/gutentags.vim b/autoload/gutentags.vim
index 8d65bd4..7a33a86 100644
--- a/autoload/gutentags.vim
+++ b/autoload/gutentags.vim
@@ -588,6 +588,7 @@ if has('nvim')
     function! gutentags#build_default_job_options(module) abort
        " Neovim kills jobs on exit, which is what we want.
        let l:job_opts = {
+                \ 'detach': 1,
                 \'on_exit': function(
                 \    '<SID>nvim_job_exit_wrapper',
                 \    ['gutentags#'.a:module.'#on_job_exit']),
@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Mar 15, 2019

I'm not too concerned with the fact that Neovim doesn't kill jobs right away on exit (if it's a problem, you could try to either file a bug upstream, or see if force-killing jobs on VimLeave does the trick). I'm more concerned about the errors (and I'd like to be able to repro them).

Also, I'd rather not detach on exit. I think it could lead to a situation where you're exiting Vim while tags are being generated, and then you start another new Vim session and another tags generation starts, while the old one isn't finished, and now you have the two of them potentially trying to write to the same files.

@emont01
Copy link

@emont01 emont01 commented May 11, 2019

I got the same error:

Error detected while processing DirChanged Autocommands for "*":
E475: Invalid argument: Channel doesn't exist
E475: Invalid argument: Channel doesn't exist
Error detected while processing function <SNR>109_nvim_job_exit_wrapper[1]..gutentags#ctags#on_job_exit[1]..gutentags#remove_job_by_data[2]..gutentags#remove_job:
line   22:
E171: Missing :endif

Just to make sure that this is not related to another plugin I created a really simple init.vim file:

call plug#begin('~/.vim/vimplug')                                                                                   
  Plug 'ludovicchabant/vim-gutentags'                                 
cal plug#end()                                                        
                                                                          
set statusline+=%{gutentags#statusline()}
                                                                      
let g:gutentags_define_advanced_commands=1
let g:gutentags_trace=1

So only vim-plug is loaded and so far everything is working as expected with NVIM v0.3.4
neovim full output when calling nvim -v is:

NVIM v0.3.4
Build type: RelWithDebInfo
LuaJIT 2.0.5
Compilation: /usr/bin/gcc-5 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/home/travis/build/neovim/bot-ci/build/neovim/build/config -I/home/travis/build/neovim/bot-ci/build/neovim/src -I/home/travis/build/neovim/bot-ci/build/neovim/.deps/usr/include -I/usr/include -I/home/travis/build/neovim/bot-ci/build/neovim/build/src/nvim/auto -I/home/travis/build/neovim/bot-ci/build/neovim/build/include
Compiled by travis@travis-job-bb83ace7-63ac-4a89-b318-3a124a2bc311

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

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "
/home/travis/build/neovim/bot-ci/build/neovim/build/nvim.AppDir/usr/share/nvim
@emont01
Copy link

@emont01 emont01 commented May 11, 2019

I have tried to find a specific plugin responsible for the problem, but I am unable to do so, using watch pgrep ctags in one terminal and vim in another I am able to kind of reproduce the problem, steps are as follows:

  • Clean my plugins folder (remove them all)
  • Delete tags folder on a big Laravel project *
  • Re-open an old vim-workspace session (3 files open: view, model and controller) and trigger PlugInstall: vim +PlugInstall
  • Close vim once PlugInstall finishes but ctags processes are still displayed by pgrep

I noticed that the error message is displayed when pgrep is showing one or 2 ctags process ids that are still running

* Project contains 6788 PHP files: included in the framework, auto-generated (cache, views, etc) or created by the team, counted them using find . -type f -name "*.php" | wc -l

phantomwhale added a commit to phantomwhale/dotfiles that referenced this issue May 13, 2019
Seems to have come in with the recent version of NeoVim

Patch was here:
ludovicchabant/vim-gutentags#178 (comment)
@voldikss
Copy link

@voldikss voldikss commented May 22, 2019

Same issue here 😞

@ruifm
Copy link

@ruifm ruifm commented Jun 5, 2019

I have the same issue. It always happens with gitcommit messages but also when I use nvim as VISUAL (VISUAL=$TERMINAL_EMULATOR -e $EDITOR) and close a file too quickly. The bug does not seem to have any negative impact except for the fact that it is annoying to see that warning once in a while.
Is is possible to mitigate this by putting some extra condition on the autocmd? An alternative would be have a global variable that can be change in one's vimrc that disables that autocmd, although I do not know to what extent that autocmd is essential.

@sheoak
Copy link

@sheoak sheoak commented Jun 20, 2019

I also have this issue. If I disable vim-virtualenv the error message disappear but I still get (after a few second lags, when saving a file):
"gutentags: ctags job failed, returned: 1%"

If I don't save the file and just quit I don't have the error.
The issue happens in a git repository, not sure if it's related.

@cstsunfu
Copy link

@cstsunfu cstsunfu commented Jul 10, 2019

I got the same error.

patrickpichler pushed a commit to patrickpichler/dotfiles that referenced this issue Aug 2, 2019
As there is a bug in gutentags which causes some errors when exiting,
gutentags is only enabled for some filetyes which are known to not cause
any issues.

This is the corresponding issue:
ludovicchabant/vim-gutentags#178
@zijiax
Copy link

@zijiax zijiax commented Aug 6, 2019

I got the same error. I do feel it's file type related. For me, it doesn't have to be git commit messages. For example, when I open a .premake file in a git directory (I guess it has to be in a git directory, because that's where the gutentags plugin works), remove a line, then ":wq", I would get it. But if I do the same with a ".cpp" or ".py" file, I won't get the error.

@zijiax
Copy link

@zijiax zijiax commented Aug 6, 2019

Some additional information for the .premake file case I mentioned, if I keep the session open long enough, I won't get the error either.

@AndreGeng
Copy link

@AndreGeng AndreGeng commented Sep 4, 2019

save error when exiting from git commit messages

@dagadbm
Copy link

@dagadbm dagadbm commented Oct 29, 2019

for people still looking for an answer as according to the author he added a workaround . i went to vim filetypes and these are ALL the git related file types possible:

let g:gutentags_exclude_filetypes = ['gitcommit', 'gitconfig', 'gitrebase', 'gitsendemail', 'git']

@ludovicchabant
Copy link
Owner

@ludovicchabant ludovicchabant commented Oct 29, 2019

It's probable that this error is what #249 was about, and should now be fixed with eb9e57f. It might be worth it populating g:gutentags_exclude_filetypes with a bunch of stuff by default though...

zackhsi added a commit to zackhsi/dotfiles that referenced this issue Oct 30, 2019
@krishnakumarg1984
Copy link

@krishnakumarg1984 krishnakumarg1984 commented Jan 14, 2020

I have exactly the same error. On nvim 0.4.3 and latest gutentags.

@dagadbm
Copy link

@dagadbm dagadbm commented Jan 17, 2020

I have solved this issue once and for all.
I will paste here the configurations I have even though I am sure some of
them do not directly impact this problem.
I think the main issue is gutentags being run on buffers that are not real
files (like GIT COMMIT buffers and so on):

let g:gutentags_add_default_project_roots = 0
let g:gutentags_project_root  = ['package.json', '.git', '.hg', '.svn']
let g:gutentags_cache_dir = expand('~/.gutentags_cache')
let g:gutentags_exclude_filetypes = ['gitcommit', 'gitconfig', 'gitrebase',
'gitsendemail', 'git']
let g:gutentags_generate_on_new = 1
let g:gutentags_generate_on_missing = 1
let g:gutentags_generate_on_write = 1
let g:gutentags_generate_on_empty_buffer = 0
let g:gutentags_ctags_extra_args = ['--tag-relative=yes',
'--fields=+ailmnS']
let g:gutentags_ctags_exclude = [
\  '*.git', '*.svn', '*.hg',
\  'cache', 'build', 'dist', 'bin', 'node_modules', 'bower_components',
\  '*-lock.json',  '*.lock',
\  '*.min.*',
\  '*.bak',
\  '*.zip',
\  '*.pyc',
\  '*.class',
\  '*.sln',
\  '*.csproj', '*.csproj.user',
\  '*.tmp',
\  '*.cache',
\  '*.vscode',
\  '*.pdb',
\  '*.exe', '*.dll', '*.bin',
\  '*.mp3', '*.ogg', '*.flac',
\  '*.swp', '*.swo',
\  '.DS_Store', '*.plist',
\  '*.bmp', '*.gif', '*.ico', '*.jpg', '*.png', '*.svg',
\  '*.rar', '*.zip', '*.tar', '*.tar.gz', '*.tar.xz', '*.tar.bz2',
\  '*.pdf', '*.doc', '*.docx', '*.ppt', '*.pptx', '*.xls',
\]
@AnderBomb
Copy link

@AnderBomb AnderBomb commented Feb 11, 2020

None of the mentioned fixes worked for me.
However the problem disappeared once I switched from exuberant-ctags to universal-ctags.

phantomwhale added a commit to phantomwhale/dotfiles that referenced this issue Mar 10, 2020
There was an issue with ctags running at 100% indefinitely when shutting
down vim whilst it's running. May have been related to
ludovicchabant/vim-gutentags#178 - can't quite
recall
@yutkat
Copy link

@yutkat yutkat commented Mar 25, 2020

@jaydorsey
Copy link

@jaydorsey jaydorsey commented Apr 10, 2020

This bug still occurs. I'm not sure if it's intended behavior but it's certainly not expected. It's not expected because I didn't expect to (potentially have to) exclude file types like JSON to prevent this error

I can trigger it consistently (100% of the time) by opening a certain json file on my system, and then doing a :wq. It doesn't even have to be done "quickly" after opening. It happens whether I make changes to the file or not

If I add json to gutentags_exclude_filetypes the error goes away. I'm adding this here in case anyone else sees the issue (this issue ranks high on search results for this issue) I understand the root cause may be something else, but excluding the file types where this happens per the comment by @dagadbm above seems to be the best solution

I appreciate that gutentags works 99% of the time so this one thing doesn't detract from it's value as a useful plugin (I ignored the error until recently when I realized it occurred 100% on certain files)

Edit: This still occurs for me on certain files, like ruby files, even if I do :w, wait for the "written" message, then :q separately. I'll try and narrow the behavior down before filing another bug report on this (there are 2 or 3 related already)

@kevsestrella
Copy link

@kevsestrella kevsestrella commented May 22, 2020

occurs to me 100% on alacritty's yaml. Just like everybody else, WA is to include the file extension in g:gutentags_exclude_filetypes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet