Instant freeze on require

[Aonodensetsu]

For obvious reasons, I am unable to provide the output of Nmlogs.

When I require this plugin on (fresh-ish) Debian 12, it freezes the nvim session, from what I can tell, permanently. I am running in tmux to recover while testing. Not calling the require but including 'netman.ui.neo-tree' in neo-tree freezes on neo-tree load.

~/.local/share/nvim/netman/logs/system shows this: ~/.local/share/nvim/netman/logs/provider is empty ~/.local/share/nvim/netman/providers.json shows this:

[miversen33]

Well that is very strange.

Are you able to reproduce this behavior with a simple configuration? I don't have a true "reproduction" script, but below is what I use for testing

-- Minimal configuration
-- mini.lua
-- Use with the --clean -u flags. EG nvim --clean -u mini.lua
-- This config will create a temp directory and will blow away that temp directory
-- everytime this configuration is loaded. Great for simulating a new installation
-- of a plugin

-- Setting some basic vim options
-- Some junk because I am sick of formatting tables in print
local _print = _G.print
local clean_string = function(...)
    local args = { n = select("#", ...), ... }
    local formatted_args = {}
    for i = 1, args.n do
        local item = select(i, ...)
        if not item then item = 'nil' end
        local t_type = type(item)
        if t_type == 'table' or t_type == 'function' or t_type == 'userdata' then
            item = vim.inspect(item)
        end
        table.insert(formatted_args, item)
    end
    return table.concat(formatted_args, ' ')
end
_G.print = function(...)
    _print(clean_string(...))
end

vim.opt.mouse = 'a'
vim.opt.termguicolors = true
-- If you want to play around with this, you can set the do_clean
-- variable to false. This will allow changes made to
-- underlying plugins to persist between sessions, while
-- still keeping everything in its own directory so
-- as to not affect your existing neovim installation.
--
-- Setting this to true will result in a fresh clone of
-- all modules
local do_clean = false
local sep = vim.loop.os_uname().sysname:lower():match('windows') and '\\' or
'/'                                                                              -- \ for windows, mac and linux both use \
local root = vim.fn.fnamemodify("./.repro", ":p")
if vim.loop.fs_stat(root) and do_clean then
    print("Found previous clean test setup. Cleaning it out")
    -- Clearing out the mods directory and recreating it so
    -- you have a fresh run everytime
    vim.fn.delete(root, 'rf')
end

-- DO NOT change the paths and don't remove the colorscheme

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
    vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
    "folke/tokyonight.nvim",
    {
        "miversen33/netman.nvim",
        config = true
    }
    -- add any other plugins here
}

require("lazy").setup(plugins, {
    root = root .. "/plugins",
})

vim.opt.splitright = true
vim.opt.splitbelow = true

vim.cmd.colorscheme("tokyonight")
-- add anything else here

Also what is your neovim version, and what branch are you using? Of course these things would be provided (ish) by Nmlogs but since Netman is just shitting the bed on you, you'll have to provide those details for me I will see if I can recreate this issue with a debian 12 container as well

[miversen33]

Reproduced in debian 12 with neovim stable (0.9.4) and netman stable. Below is a dockerfile to recreate this issue

FROM debian:12

ARG VERSION

ENV NEOVIM_VERSION=${VERSION:-stable}
ENV NEOVIM_INSTALL_LOCATION=/opt/

RUN \
    apt-get update -y 2>&1 1>/dev/null &&\
    apt-get install -y \
        git \
        curl \
        bash \
        # Dependencies for treesitter
        gcc \
        g++ &&\
    cd /usr/local/bin &&\
    # Setting up neovim
    curl -L "https://github.com/neovim/neovim/releases/download/${NEOVIM_VERSION}/nvim-linux64.tar.gz" | tar -C "${NEOVIM_INSTALL_LOCATION}" -xz &&\
    # Creating a link to /usr/local/bin for neovim
    ln -s ${NEOVIM_INSTALL_LOCATION}/nvim-linux64/bin/nvim /usr/local/bin/nvim

RUN echo "-- Minimal configuration\n\
-- mini.lua\n\
-- Use with the --clean -u flags. EG nvim --clean -u mini.lua\n\
-- This config will create a temp directory and will blow away that temp directory\n\
-- everytime this configuration is loaded. Great for simulating a new installation\n\
-- of a plugin\n\
\n\
-- Setting some basic vim options\n\
-- Some junk because I am sick of formatting tables in print\n\
local _print = _G.print\n\
local clean_string = function(...)\n\
    local args = { n = select('#', ...), ... }\n\
    local formatted_args = {}\n\
    for i = 1, args.n do\n\
        local item = select(i, ...)\n\
        if not item then item = 'nil' end\n\
        local t_type = type(item)\n\
        if t_type == 'table' or t_type == 'function' or t_type == 'userdata' then\n\
            item = vim.inspect(item)\n\
        end\n\
        table.insert(formatted_args, item)\n\
    end\n\
    return table.concat(formatted_args, ' ')\n\
end\n\
_G.print = function(...)\n\
    _print(clean_string(...))\n\
end\n\
\n\
vim.opt.mouse = 'a'\n\
vim.opt.termguicolors = true\n\
-- If you want to play around with this, you can set the do_clean\n\
-- variable to false. This will allow changes made to\n\
-- underlying plugins to persist between sessions, while\n\
-- still keeping everything in its own directory so\n\
-- as to not affect your existing neovim installation.\n\
--\n\
-- Setting this to true will result in a fresh clone of\n\
-- all modules\n\
local do_clean = false\n\
local root = vim.fn.fnamemodify('./.repro', ':p')\n\
if vim.loop.fs_stat(root) and do_clean then\n\
    print('Found previous clean test setup. Cleaning it out')\n\
    -- Clearing out the mods directory and recreating it so\n\
    -- you have a fresh run everytime\n\
    vim.fn.delete(root, 'rf')\n\
end\n\
\n\
-- DO NOT change the paths and don't remove the colorscheme\n\
\n\
-- set stdpaths to use .repro\n\
for _, name in ipairs({ 'config', 'data', 'state', 'cache' }) do\n\
    vim.env[('XDG_%s_HOME'):format(name:upper())] = root .. '/' .. name\n\
end\n\
\n\
-- bootstrap lazy\n\
local lazypath = root .. '/plugins/lazy.nvim'\n\
if not vim.loop.fs_stat(lazypath) then\n\
    vim.fn.system({ 'git', 'clone', '--filter=blob:none', 'https://github.com/folke/lazy.nvim.git', lazypath, })\n\
end\n\
vim.opt.runtimepath:prepend(lazypath)\n\
\n\
-- install plugins\n\
local plugins = {\n\
    'folke/tokyonight.nvim',\n\
    {\n\
        'miversen33/netman.nvim',\n\
        config = true\n\
    }\n\
    -- add any other plugins here\n\
}\n\
\n\
require('lazy').setup(plugins, {\n\
    root = root .. '/plugins',\n\
})\n\
\n\
vim.opt.splitright = true\n\
vim.opt.splitbelow = true\n\
\n\
vim.cmd.colorscheme('tokyonight')\n\
-- add anything else here\n\
" > /tmp/repro.lua

# Volume mount stuff here so you can use neovim with your code and get whatever files neovim generates out here
WORKDIR /mnt

ENTRYPOINT [ "/usr/local/bin/nvim", "--clean", "-u", "/tmp/repro.lua" ]

Some more notes, I have also recreated this in ubuntu with both nightly and stable. I am very curious what is happening here but at least I can reproduce the issue. I will tag you when I get something figured out. Thank you for bringing this to my attention!

[miversen33]

@Aonodensetsu I am not able to recreate this issue using the v1.15 branch. Can you verify that this branch does not cause the same freezing for you?

There are some significant difference between main and the version branches but the fact that I am not seeing the issue here makes me think there is something wrong with the base startup that is looping. I don't even see the core logs being created when running the "main" branch in the container. Which is... odd.

[Aonodensetsu]

Hey, I previously had this problem on raspberry pi, debian 11, but decided it was an architecture issue. Now i migrated to an x64 system and the same happens so it seems like a debian issue. I'm using nvim nightly (master), but it's good to see the issue is reproducible.

[Aonodensetsu]

i'll get to the pc in about an hour, will check then

[miversen33]

Just a quick guess. Your debian machine does not have docker installed on it, is that correct? The issue (in my reproducible instance) is related to the docker provider falling over. I don't think the issue has anything to do with the distro or version of neovim being ran.

What is weird though is I patched this bug out a while ago (if its the bug I think it is), though maybe that patch hasn't made its way to main. This is almost certainly related to #113 though in this case instead of timing out (which it should be), it is instead just running forever waiting for a command that is likely already dead.

[Aonodensetsu]

I indeed do not have docker, branch v1.15 works.

[miversen33]

I indeed do not have docker, branch v1.15 works.

My theory checks out. Humor me, can you manually disable the docker provider by editing the lua/providers/init.lua file and commenting (appending --) the line that says "netman.providers.docker". If that corrects your issue as well then I have indeed recreated it completely and have some idea of how to approach resolving it (likely pulling in the upstream patch for shell.lua

[Aonodensetsu]

This solves the issue also.

[miversen33]

Ok so I know the general issue, though I don't know what line(s) exactly are causing the problem. My suspicion that the patch that "fixed" this has already been pulled into main is correct and thus this is a different but "samey" issue.

As you have a few work arounds for this, I am going to sleep on it and see if I can puzzle through this tomorrow. I appreciate you pointing this issue out! I really need to get around to fleshing out my testing for netman, after about a billion other things lol

[Aonodensetsu]

i added tests to my prev-gen app in like version 5.0 or something stupid like that, it happens i'm going to be using the branch temporarily

[miversen33]

Ok so I figured out the issue here.

In a nutshell what is happening here is that the "docker -v" command is failing (for obvious reasons in your case). This failure means that the command is already finished before we enter the no-async loop (a loop designed to "lock" the thread until the spawned process completes or times out).

I am not quite sure why the job isn't being timed out properly (I believe this is an artifact of how I am closing out the STDIN pipe but I guess that doesn't always trigger the "exit" event on a luv process?) but that is not something I am going to look into as the entire issue has been corrected on the incoming v1.15 branch. As such, the solution here is pretty simple. If we die before we start the no-async loop, then just skip the no-async loop.

@Aonodensetsu can you try out the 174-fix-failure-to-clean-fail branch and see if it works for you?

[miversen33]

Given the lack of screaming or gnashing of teeth, I am going to assume that this is no longer an issue. Closing this out.

If it is still an issue, please feel free to reopen it