Segfaults during creation of user-defined commands in macOS (aarch64)

[ReeceStevens]

Hi all!

Firstly, thank you for the awesome work y'all are doing to make Rust accessible for neovim plugin writers!

I'm using nvim-oxi to write a plugin and have run into what appears to be a macos-specific issue. I only have access to an M1 mac, so I don't know for sure if this happens on intel macs or not. I do have access to a linux box, and I have confirmed the issue does not show up on linux (arch linux x86).

I'm seeing segfaults any time I try to execute a user-defined command. Here's my reproducible code snippet:

use nvim_oxi as oxi;
use nvim_oxi::types::{CommandArgs, CommandNArgs, CommandRange};
use nvim_oxi::opts::CreateCommandOpts;
use nvim_oxi::api;

#[oxi::module]
fn vim_plugin_test() -> oxi::Result<u32> {
    let opts = CreateCommandOpts::builder().build();

    let greetings = move |args: CommandArgs| {
        api::out_write("Test");
        Ok(())
    };

    api::create_user_command("Greetings", greetings, Some(&opts))?;

    Ok(42)
}

I also have the linker arguments for macos as described in your examples directory:

# .cargo/config
[target.x86_64-apple-darwin]
rustflags = [
  "-C", "link-arg=-undefined",
  "-C", "link-arg=dynamic_lookup",
]

[target.aarch64-apple-darwin]
rustflags = [
  "-C", "link-arg=-undefined",
  "-C", "link-arg=dynamic_lookup",
]

My project builds with no issues, and I can confirm the user-defined command is accessible from neovim-- it shows up in tab completion. However, when I actually run :Greetings<CR>, neovim dies with Segmentation fault: 11.

I don't think this is an issue with code signing-- I got a different error (Killed: 9) when that was the case. I am now running codesign on the produced libraries and that seems to work just fine.

Any advice you have on next investigation steps would be much appreciated. Unfortunately GDB does not work on M1 architectures, but I have run neovim through lldb and got the following stack trace on the error:

:GreetingsProcess 44524 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xa)
    frame #0: 0x0000000196c53274 libsystem_platform.dylib`_platform_memmove + 420
libsystem_platform.dylib`_platform_memmove:
->  0x196c53274 <+420>: ldr    x6, [x1], #0x8
    0x196c53278 <+424>: str    x6, [x3], #0x8
    0x196c5327c <+428>: subs   x2, x2, #0x8              ; =0x8
    0x196c53280 <+432>: b.hs   0x196c53274               ; <+420>
Target 0: (nvim) stopped.
(lldb) bt
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xa)
  * frame #0: 0x0000000196c53274 libsystem_platform.dylib`_platform_memmove + 420
    frame #1: 0x0000000103d31eec vim_plugin_test.so`core::ptr::read::h9e01436829227460(src=0x000000000000000a) at mod.rs:1115:9
    frame #2: 0x0000000103d3843c vim_plugin_test.so`_$LT$nvim_types..dictionary..DictIterator$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::hc4c389472e824fba(self=0x000000016fdfc560) at dictionary.rs:128:52
    frame #3: 0x0000000103d2e550 vim_plugin_test.so`_$LT$nvim_oxi..object..de..MapDeserializer$u20$as$u20$serde..de..MapAccess$GT$::next_key_seed::h36af9d336687008b(self=0x000000016fdfc560, seed=PhantomData<nvim_oxi::api::types::command_args::_::{impl#0}::deserialize::__Field> @ 0x000000016fdfb15f) at de.rs:242:39
    frame #4: 0x0000000103d28ed0 vim_plugin_test.so`serde::de::MapAccess::next_key::ha2ac654861086e10(self=0x000000016fdfc560) at mod.rs:1854:9
    frame #5: 0x0000000103d28a70 vim_plugin_test.so`_$LT$$RF$mut$u20$A$u20$as$u20$serde..de..MapAccess$GT$::next_key::hf70525b52654ea59(self=0x000000016fdfb3a8) at mod.rs:1944:9
    frame #6: 0x0000000103d38d78 vim_plugin_test.so`_$LT$nvim_oxi..api..types..command_args.._..$LT$impl$u20$serde..de..Deserialize$u20$for$u20$nvim_oxi..api..types..command_args..CommandArgs$GT$..deserialize..__Visitor$u20$as$u20$serde..de..Visitor$GT$::visit_map::h778579db4598e380(self=(marker = core::marker::PhantomData<nvim_oxi::api::types::command_args::CommandArgs> @ 0x000000016fdfc43e, lifetime = core::marker::PhantomData<void *> @ 0x000000016fdfc43e), __map=0x000000016fdfc560) at command_args.rs:12:45
    frame #7: 0x0000000103d2e1b4 vim_plugin_test.so`_$LT$nvim_oxi..object..de..Deserializer$u20$as$u20$serde..de..Deserializer$GT$::deserialize_map::hbb41dd910ef1931e(self=Deserializer @ 0x000000016fdfc730, visitor=(marker = core::marker::PhantomData<nvim_oxi::api::types::command_args::CommandArgs> @ 0x000000016fdfc67f, lifetime = core::marker::PhantomData<void *> @ 0x000000016fdfc67f)) at de.rs:171:17
    frame #8: 0x0000000103d2e270 vim_plugin_test.so`_$LT$nvim_oxi..object..de..Deserializer$u20$as$u20$serde..de..Deserializer$GT$::deserialize_struct::h1c7c2cd4a8b36d84(self=<unavailable>, _name=(data_ptr = "CommandArgsreg", length = 11), _fields=&[&str] @ 0x000000016fdfc768, visitor=(marker = core::marker::PhantomData<nvim_oxi::api::types::command_args::CommandArgs> @ 0x000000016fdfc77f, lifetime = core::marker::PhantomData<void *> @ 0x000000016fdfc77f)) at de.rs:191:9
    frame #9: 0x0000000103d3853c vim_plugin_test.so`nvim_oxi::api::types::command_args::_::_$LT$impl$u20$serde..de..Deserialize$u20$for$u20$nvim_oxi..api..types..command_args..CommandArgs$GT$::deserialize::ha3ed7f8afb11d764(__deserializer=<unavailable>) at command_args.rs:12:45
    frame #10: 0x0000000103d384e0 vim_plugin_test.so`_$LT$nvim_oxi..api..types..command_args..CommandArgs$u20$as$u20$nvim_oxi..object..from_object..FromObject$GT$::from_obj::h8776a94f554c1fc3(obj=<unavailable>) at command_args.rs:53:9
    frame #11: 0x0000000103d265c4 vim_plugin_test.so`_$LT$A$u20$as$u20$nvim_oxi..lua..poppable..LuaPoppable$GT$::pop::ha691d818a34416d5(lstate=0x000000010070c380) at poppable.rs:46:9
    frame #12: 0x0000000103d27f94 vim_plugin_test.so`nvim_oxi::lua::fun::Function$LT$A$C$R$GT$::from_fn::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h1f0421eb4ed04d2f(l=0x000000010070c380) at fun.rs:104:45
    frame #13: 0x0000000103d30fbc vim_plugin_test.so`nvim_oxi::lua::fun::Function$LT$A$C$R$GT$::from_fn::c_fun::hdd04c61c9bcb723d(lstate=0x000000010070c380) at fun.rs:100:13
    frame #14: 0x0000000100734238 libluajit-5.1.2.dylib`___lldb_unnamed_symbol96$$libluajit-5.1.2.dylib + 44
    frame #15: 0x0000000100740d80 libluajit-5.1.2.dylib`lua_pcall + 148
    frame #16: 0x000000010012c368 nvim`nlua_pcall + 120
    frame #17: 0x000000010012decc nvim`nlua_do_ucmd + 1368
    frame #18: 0x000000010024109c nvim`do_ucmd + 208
    frame #19: 0x00000001000d578c nvim`execute_cmd0 + 140
    frame #20: 0x00000001000d261c nvim`do_cmdline + 12264
    frame #21: 0x00000001001761c0 nvim`nv_colon + 416
    frame #22: 0x0000000100173be8 nvim`normal_execute + 4172
    frame #23: 0x000000010020ad44 nvim`state_enter + 360
    frame #24: 0x0000000100137b60 nvim`main + 10716
    frame #25: 0x000000010039508c dyld`start + 520
(lldb)

My best parse of this is that it's related to argument parsing or handling during the processing of the user-defined command. Perhaps relatedly, I noticed that using CommandNArgs::One in the creation of the command caused an immediate crash of neovim on launch with the following error:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: NvimError("Invalid value for \'nargs\'")', /Users/reecestevens/.cargo/registry/src/github.com-1ecc6299db9ec823/nvim-oxi-0.1.3/src/lua/lua.rs:42:12
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/result.rs:1814:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/result.rs:1107:23
   4: nvim_oxi::lua::lua::module_entrypoint
             at /Users/reecestevens/.cargo/registry/src/github.com-1ecc6299db9ec823/nvim-oxi-0.1.3/src/lua/lua.rs:42:5
   5: luaopen_vim_plugin_test
             at ./src/lib.rs:6:1
   6: <unknown>
   7: _luaL_openlibs
   8: <unknown>
   9: _lua_pcall
  10: _nlua_pcall
  11: _nlua_typval_exec
  12: _ex_lua
  13: _execute_cmd0
  14: _do_cmdline
  15: _do_source
  16: _cmd_source
  17: _execute_cmd0
  18: _do_cmdline
  19: _source_using_linegetter
  20: _nvim_exec
  21: _nlua_api_nvim_exec
  22: <unknown>
  23: _lua_pcall
  24: _nlua_pcall
  25: _nlua_typval_exec
  26: _ex_lua
  27: _execute_cmd0
  28: _do_cmdline
  29: _do_source
  30: _main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: Rust panics must be rethrown

If you have any bandwidth to review these stack traces and let me know what you think, I would really appreciate it. Thanks again!

[noib3]

What version of Neovim does this happen on?

[ReeceStevens]

I feel pretty foolish for this oversight-- it is happening on neovim 0.8.0. Looking back at my linux box, I was still running 0.7.2 on there, and after upgrading I also see a segfault. So, my assumption about this being macos-specific seems to be incorrect.

I will try and downgrade my macOS neovim instance to 0.7.2 and see if my test case starts working again. Is there any other information you need that might be helpful?

[noib3]

Plugins created with nvim-oxi are compiled against a specific version of Neovim. Before Neovim 0.8.0 was released the default was to build against 0.7.2, and we had a nightly feature flag to enable for targeting Neovim nightly. I'm assuming you didn't enable that feature so your plugin is being compiled for 0.7.2 but loaded by 0.8.0, causing the segfault.

With that said, this system has been recently rewritten to be more explicit, and it'll be added in the 0.2.0 release of nvim-oxi in the coming days.

In the meantime I'd suggest using the latest master of nvim-oxi in your Cargo.toml. Then you'll have to enable one of the neovim-0-7, neovim-0-8 or neovim-nightly features depending on the Neovim version you're targeting.

There were also some breaking changes since 0.1.3 so the code above won't compile. This should however:

use nvim_oxi as oxi;
use nvim_oxi::api::{
    self,
    opts::CreateCommandOpts,
    types::{CommandArgs, CommandNArgs, CommandRange},
};

#[oxi::module]
fn vim_plugin_test() -> oxi::Result<u32> {
    let opts = CreateCommandOpts::builder().build();

    let greetings = move |args: CommandArgs| {
        api::out_write("Test");
        Ok(())
    };

    api::create_user_command("Greetings", greetings, &opts)?;

    Ok(42)
}

(btw, you can use CreateCommandOpts::default() instead of builder().build()).

[ReeceStevens]

@noib3 thank you so much for your quick, detailed, and very helpful responses. You were right on the money; I needed to compile against neovim 0.8.0. After doing so, I was able to get my plugin up and running.

I'm going to go ahead and close this issue. I appreciate the help!