neovim-remote: Nvim segfaults

Also experiencing this issue on Ubuntu 19.10, running nvim v0.3.8, but I don’t have deoplete installed.

Removing the nvimsocket file as well as any existing nvim folders from /tmp fixed it for me:

rm -f /tmp/nvimsocket
rm -rf /tmp/nvim*

Despite that the bug has been identified as mentioned above, and that I have no idea what the problem really is, I would like to share some of my own experience.

I am on Fedora 30, and installed neovim from the copr repository agriffis/neovim-nightly. I started to have this problem long time ago. I regularly do sudo dnf upgrade so I am always using the latest version of neovim. At certain point, I got the core dump problem. After some experiment, I found that if I do not upgrade the python3-neovim package, I would have no problem. After that I started to do my upgrade by always excluding python3-neovim. Today I did something wrong and messed everything up. So I want to do a fresh install of neovim and neovim-remote. After quite lots of tries, I found that if I use the pynvim-0.3.2, then the problem disappears.

The version of pynvim installed by pip3 install neovim-remote would be the latest 0.4.1. The version of python3-neovim (fedora packaged pynvim) from agriffis/neovim-nightly is 0.4.0.0.git.567.2cbc135. Neither of them work with my latest nvim install. So I uninstalled the pynvim-0.4.1, and installed 0.3.2, then the problem solved.

pip3 install neovim-remote --user
pip3 uninstall pynvim
pip3 install pynim==0.3.2 --user

Now I have the following instals.

➜  ~ pip3 list --user
Package       Version
------------- -------
greenlet      0.4.15 
msgpack       0.6.2  
neovim-remote 2.4.0  
pynvim        0.3.2

➜  ~ nvim -version
NVIM v0.5.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/builddir/build/BUILD/neovim-0.4.3.0.git.13550.bb331a9b3/build/config -I/builddir/build/BUILD/neovim-0.4.3.0.git.13550.bb331a9b3/src -I/usr/include -I/usr/include/lua-5.1 -I/builddir/build/BUILD/neovim-0.4.3.0.git.13550.bb331a9b3/build/src/nvim/auto -I/builddir/build/BUILD/neovim-0.4.3.0.git.13550.bb331a9b3/build/include
Compiled by mockbuild

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

I’ve got a similar issue here.

1. python is version 3.8.0
2. there is a file nvr/nvr.py in the directory from pip show neovim-remote | grep Location

I’d add I’m using archlinux.

Here is the result of the core dump obtained via coredumpctl info <PID>:

           PID: 1138 (nvim)
           UID: 1000 ([...])
           GID: 1000 ([...])
        Signal: 6 (ABRT)
     Timestamp: Wed 2019-12-11 17:07:55 CET (8min ago)
  Command Line: nvim
    Executable: /usr/bin/nvim
 Control Group: /user.slice/user-1000.slice/session-2.scope
          Unit: session-2.scope
         Slice: user-1000.slice
       Session: 2
     Owner UID: 1000 ([...])
[...]
       Storage: /var/lib/systemd/coredump/core.nvim.1000.3549dd4d1b664a53a3df7680e40c521c.1138.1576080475000000000000.lz4
       Message: Process 1138 (nvim) of user 1000 dumped core.
                
                Stack trace of thread 1138:
                #0  0x00007f87ec208f25 raise (libc.so.6)
                #1  0x00007f87ec1f2897 abort (libc.so.6)
                #2  0x000055f3f200212d n/a (nvim)
                #3  0x000055f3f2214120 handle_nvim_set_client_info (nvim)
                #4  0x000055f3f21044b2 n/a (nvim)
                #5  0x000055f3f2196009 multiqueue_process_events (nvim)
                #6  0x000055f3f20f3313 n/a (nvim)
                #7  0x000055f3f2100e1f n/a (nvim)
                #8  0x000055f3f205d201 state_enter (nvim)
                #9  0x000055f3f21025dc normal_enter (nvim)
                #10 0x000055f3f2003d37 main (nvim)
                #11 0x00007f87ec1f4153 __libc_start_main (libc.so.6)
                #12 0x000055f3f2004dce _start (nvim)
                
                Stack trace of thread 1140:
                #0  0x00007f87ec2cc60e epoll_wait (libc.so.6)
                #1  0x00007f87ec194f9a uv__io_poll (libuv.so.1)
                #2  0x00007f87ec184fb7 uv_run (libuv.so.1)
                #3  0x000055f3f2196226 loop_poll_events (nvim)
                #4  0x000055f3f204b59e n/a (nvim)
                #5  0x00007f87ec15c4cf start_thread (libpthread.so.0)
                #6  0x00007f87ec2cc2d3 __clone (libc.so.6)

Seems like the core dump, if it’s the same issue, is more related to how nvim is launched maybe ?

Also, I would add, the core dump only happens on first launch after boot, then, nvim starts, but I get a message (printed to stdout) that says :

[!] Unable to attach to the new nvim process. Is `nvim` working?

At this point it is possible to use nvr if you specify an existing nvim socket, like so for example :

$ nvr --servername /tmp/nvimO8eRzb/0 something_useful

EDIT: after the first core dump, a file called /tmp/nvimsocket is created. If I delete this file and try to launch nvr without any argument again, I get a new core dump.

Can confirm @Shatur95 suggestion works great; I have this in .bashrc:

nvr() {
    if [[ -S "$NVIM_LISTEN_ADDRESS" ]]; then
        command nvr -s "$@"
    else
        nvim -- "$@"
    fi
}

@mhinz any downside if nvr started providing said check?

I use the following script:

if [ -S $NVIM_LISTEN_ADDRESS ]; then
    nvr --remote-wait -s "$@"
else
    $NVR_CMD --nofork -- "$@"
fi

It simply spawn nvr only if neovim is launched, otherwise it just start neovim ($NVR_CMD is neovim-qt on my machine). It works perfectly for me without any crashes. I think that such check should be by default.

@haoyun suggestion works also for me

Thanks

+1

@haoyun suggestion to downgrade pynvim to 0.3.2 worked for me as well

Well, whatever the plugins are doing, they trigger a condition that makes Nvim segfault and Nvim should never segfault. And according to this comment, the problem is understood. It just needs someone to come up with a fix.