nvim-oxi: Crash when loading the example plugin on Windows

Hello, I am using the crate setup example from the repo and Neovim crashes when loading the plugin DLL file by requiring the module. I am copying the DLL directly to NeoVim’s bin directory.

The nvim process crashes with virtually no way to debug it. I tried the latest git version of nvim-oxi. I am on Windows, I added the /force:UNRESOLVED flags to my cargo config:

[target.x86_64-pc-windows-msvc]
rustflags = [
  "-C", "link-arg=/FORCE:UNRESOLVED",
]

[target.aarch64-pc-windows-msvc]
rustflags = [
  "-C", "link-arg=/FORCE:UNRESOLVED",
]

About this issue

  • Original URL
  • State: closed
  • Created 6 months ago
  • Comments: 29 (12 by maintainers)

Most upvoted comments

Not necessarily, the .lib files only contain function definitions to interface with the symbols inside nvim.exe at link time. After thorough testing, I can confirm that both nvim.lib and lua51.lib work interchangeably in NeoVim nightly and 0.9, everything works as long as you are compiling with the correct version feature.

If storing the .lib files is an issue, I can write a script that generates a nvim.lib using dumpbin.exe. However, the user will need NeoVim installed to build the crate.

I can use https://github.com/SecSamDev/dumpbin inside build.rs

@theofabilous could you open a PR? Imo there’s no point in blocking this over whose PR gets merged.

On another note, I think I’ve found an alternative solution by tweaking rust’s linker attributes. CI seems to be passing on windows, I’ll look into submitting a PR soon

@theofabilous Credits where credits due.

I used Rust’s built-in #[link] attribute above each extern C. When setting the link-type to raw-dylib, rustc automatically generates an import library. This solved the issue without providing our import libraries. Most importantly, it now relies on the NeoVim executable, making the fix compatible with all versions.

I added a mechanism to locate the NeoVim installation directory, it will look for NeoVim in the PATH and then in an environment variable NVIM_DIR.

These changes are reflected in my PR.

You are right, any call to nvim API segfaults with an access violation error. I tried debugging the nvim process in VS. devenv_WTHsOHMTmd

It seems like nvim.exe links libnvim statically as well. So I can’t really access the nvim symbols, can I? dumpbin.exe indeed shows the nvim_* symbols as exported.

I’m encountering this as well. Crashes immediately upon requiring the module. I’m running on NVIM v0.10.0-dev-2135+g98a4ed0a1 and current git main for the nvim-oxi dependency