Any invocation of Silicon causes the filetype to pull in random characters

[PriceHiller]

The Bug

Currently invoking Silicon causes weird strings to fill filetype as shown in the video below:

out.mp4

In the top right, on the winbar, it displays the filetype which seems to be wholly random after invocation. Attempting to use Neovim after a Silicon invocation leads to very weird behavior. This occurs both with writing to a file and using the copy functionality.

Now, manually setting the filetype back to the original filetype fixes the issue. I'm unsure where this bug is coming from, but I'm assuming there's an open write somewhere that wasn't properly dropped/closed.

System Information

Nvim Version Info:

NVIM v0.9.0-dev-1051+g1d8b77da6
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-10 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wno-unused-result -Wimplicit-fallthrough -Wvla -fno-common -fdiagnostics-color=always -fstack-protector-strong -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DMIN_LOG_LEVEL=3 -DNVIM_UNIBI_HAS_VAR_FROM -I/home/runner/work/neovim/neovim/.deps/usr/include/luajit-2.1 -I/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include -I/home/runner/work/neovim/neovim/build/cmake.config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include -I/home/runner/work/neovim/neovim/.deps/usr/include

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

Run :checkhealth for more info

Output of uname -a:

Linux orion 6.1.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 14 Feb 2023 22:08:08 +0000 x86_64 GNU/Linux

Hash version of silicon.nvim that was used (should be the latest):

da4c153806a61aa231a153ac42524ffe723908c5
-> Short: da4c153 (HEAD, origin/main, origin/HEAD) refactor: fix clippy warnings

I also ensured I rebuilt silicon.nvim manually via bash ~/.local/share/nvim/lazy/silicon.nvim/install.sh build

silicon.nvim config w/ Lazy:

{
    "krivahtoo/silicon.nvim",
    build = "./install.sh build",
    config = function()
        require("silicon").setup({
            font = "Hack=20",
            theme = "Monokai Extended",
            background = "#87F",
            pad_vert = 60,
            pad_horiz = 40,
            line_number = true,
            window_title = function()
                return vim.fn.fnamemodify(vim.fn.bufname(vim.fn.bufnr()), ":~:.")
            end,
        })
    end,
}

Link to my latest relevant configuration:
See my neovim configuration here.

PR

I am more than happy and willing to get a PR out to fix this issue, but I'm unsure as to where this problem is even appearing from. It may be purely stemming from me being on Linux for all I know. Any pointers to the source of the problem are welcome, I'm willing to fix this if I can get an idea of where the filetype might be getting nuked from.

[PriceHiller]

Update, I have determined this is likely a bug in nvim_oxi. Commenting everything within the save_image function up to the oxi invocation to get the filetype option:

let ft: oxi::String = Buffer::current().get_option("filetype")?;

still leads to this odd behavior. Upon commenting the get_option line (L39) the filetype weirdness no longer occurs. Seems oxi is screwing up buffer mem or something like that.

[krivahtoo]

Yeah, I got the same issue, but only on nightly version.
I think the issue is neovim api returns a string pointer that gets freed by rust.

related: noib3/nvim-oxi#89