Nvim segfaults

[michaelslec]

fresh install of neovim-remote. Installed via

pip3 install neovim-remote

running via python ~/.local/bin/nvr reveals that

Traceback (most recent call last):
File ".local/bin/nvr", line 6, in
from nvr.nvr import main
ImportError: No module named nvr.nvr

Thanks

EDIT: python ~/.local/bin/nvr is a mistake on my part. It should be python3 ~/.local/bin/nvr which then reveals the same issue abore (core dump) nvr

For clarification and future readers, here is my NVIM info:

NVIM v0.4.3
Build type: RelWithDebInfo
LuaJIT 2.0.5
Compilation: /usr/bin/gcc-5 -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 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fdiagnostics-color=auto -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-9a287301-34f2-4b86-92e3-462594f51f36

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

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

[mhinz]

I'm closing this since I'm pretty sure that it's not an issue with this package but a configuration problem. But we can figure out the problem here anyway.

1. Is python --version really at least Python 3.5?
2. When you installed with pip3 install ..., then python3 -c 'import site; print(site.getsitepackages())' should show you the directory for these site packages. In one of these directories should be a directory called nvr with a file called nvr.py. (EDIT: It's probably easier to just use this: pip3 show neovim-remote | grep Location.)
3. The abort (core dumped) nvr issue is another hint for something being broken. The Python process should never segfault just because it didn't find a package.

[FractalWire]

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.

[mhinz]

Oh, so Nvim segfaults.

1. Which Nvim version is it exactly? (nvim --version | grep NVIM)
2. How did you install Nvim?

[mhinz]

I guess it's this bug: neovim/neovim#11052

Although there's nothing I can do about it, I let this open for a while, since it's likely that others experience this issue as well.

I can't look into it myself, since I can't reproduce it neither with macOS 10.15 nor in an Ubuntu VM.

Maybe you can help Justin out there in that issue? :)

[michaelslec]

In the mean time, @mhinz, what version of NVIM are you working with? I want to downgrade because I love nvr. I'm using v0.4.3

[mhinz]

When forking a new process, nvr defaults to whatever nvim is in $PATH. (You can use another executable for testing via $NVR_CMD.)

I tried:

• v0.4.3 Release from Homebrew
• master built from source on macOS and then VIMRUNTIME=runtime NVR_CMD=build/bin/nvim nvr from the repo root directory.

[FractalWire]

It seems like it is related to neovim/neovim#11052 indeed.

In my case however, coc.nvim is not at fault, but it is deoplete. Removing that plugin from my plugin list make nvim works fine when launched by nvr.

For reference, I'm using nvim 0.4.3 version and deoplete version 5.2

nvim with nvr was working fine with an earlier version of nvim and/or with an earlier version of deoplete (that I updated quite recently too...)

[FractalWire]

Seems like everything works fine until deoplete commit Shougo/deoplete.nvim@eab0bf6

I don't know if it's a neovim or Deoplete issue. And I still don't get why nvim is working fine with deoplete when nvr is not involved.

[mhinz]

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.

[peter-lucia]

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*

[mhinz]

@peter-lucia

It's sad to hear that so many people experience this bug, but I don't see any way to fix this from neovim-remote. This needs to be fixed in Nvim.

You get a segfault if there is a /tmp/nvimsocket? Or just the couldn't attach message, which would be expected in this case? (This happens when Nvim quits unexpectedly and has no time to remove /tmp/nvimsocket again.)

What you could all try is using TCP by default. E.g. by putting export NVIM_LISTEN_ADDRESS=localhost:12345 in your shell config. Then nvr and the first nvim process would use that address by default. Not sure if it helps with the segfault, but it certainly works around the stale Unix domain socket (/tmp/nvimsocket), if Nvim crashes.

[peter-lucia]

I should have clarified, I don't think removing the stale files and folders in /tmp fixed the segfault, but it did fix the [!] Unable to attach to the new nvim process. Is `nvim` working?.

IIRC, to fix the segfault, I think the issue was I hadn't added "NVIM_LISTEN_ADDRESS=/tmp/nvimsocket" to ~/.bashrc.

After that, upon trying to start neovim with nvr -s, I was getting the following message: [!] Unable to attach to the new nvim process. Is `nvim` working?. I realized there were stale /tmp/nvimsocket files and /tmp/nvimXYZ folders, so I deleted them, and after retrying to start neovim with nvr, I stopped seeing any errors.

[haoyun]

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

[bockel]

+1

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

[jdeut]

@haoyun suggestion works also for me

Thanks

[Shatur]

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.

[laur89]

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?