NvimServer segfaults when used with --headless --cmd

[ibhagwan]

Hi,

I maintain the fzf-lua neovim plugin, the plugin relies heavily on processing commands with a headless neovim instance, this seems to segfault the neovim build that comes with VimR, for example:

fzf-lua takes the path from v:progpath

❯ '</path/to/>/VimR.app/Contents/Resources/NvimView_NvimView.bundle/Contents/Resources/NvimServer' -n --headless --cmd 'lua print("test")'
zsh: segmentation fault   -n --headless --cmd 'lua print("test")

Vs a normal build:

❯ nvim -n --headless --cmd 'lua print("test\n"); os.exit(0)'
test

This was discovered as part of ibhagwan/fzf-lua#651

Edit: This seems to be related to #984 and #993, neogit also uses --headless and has the same issue NeogitOrg/neogit#438

[SolaWing]

VIMR encapsulates the NVIM command-line interface and directly couples the GUI's startup parameters.

I tried modifying the vimr to expose the original interface and capabilities of the NVIM, which worked under my simple tests, but I wasn't too sure that there would be other unanticipated effects. The corresponding commit is in my own branch: https://github.com/SolaWing/vimr/tree/nvim-binary and https://github.com/SolaWing/neovim/tree/nvim-binary. if it's ok I can push a pr.

By the way, NVIM 0.9 mentioned that ui_bridge will be removed, see #996, maybe migrating to RPC and using the original unchanged core NVIM is a better approach.

What do you think @qvacua

[georgeharker]

Same here with neogit, it would be awesome to understand what's going on here - looking at the above PR by @SolaWing this looks pretty reasonable. I'd +1 to migrating to RPC though

[georgeharker]

Can confirm the above changes work (after some code signing headaches, but that's nothing to do with the changes)

[georgeharker]

@SolaWing could you file a PR for this?