vim.loop.walk() aborts every time (failed assertion)

[norcalli]

NVIM v0.4.2
Build type: Release
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.2/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

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

Run :checkhealth for more info

Steps to reproduce using nvim -u NORC

❯ nvim -u NORC +'lua vim.loop.walk(print)'
nvim: /build/libluv/src/luv-1.30.1-0/src/loop.c:82: luv_walk_cb: Assertion `data && data->ref < 0x1000000' failed.
fish: “nvim -u NORC +'lua vim.loop.wal…” terminated by signal SIGABRT (Abort)

It appears that neovim is allocating handles outside of the range expected by luv. I think that luv would need to be altered to remove that assertion or another function (or perhaps just override vim.loop.walk) should be provided which behaves correctly.

I want to use uv.walk to be able to provide a job system which can look for existing timers, watchers, and others to display or clean up resources, so I would call it an essential function, as there is no other way to discover handles without hooking into every new_* method.

[bfredl]

luv.walk assumes that all handles are owned by luv, so that they can be cast to luv's own wrapper type. I think we need to wrap/replace this functionality safely from nvim.

[norcalli]

Yeah that's what I figured. luv.walk shouldn't have been exposed in the first place if it aborts immediately, so if we're worried about API compatibility, we can replace it fine, but it may be misleading since it's the only function that wouldn't be directly equivalent to the luv ones.

I have a feeling that the vim.loop functionality will evolve greatly, though, before it's stabilized anyway.

[zeertzjq]

Closing in favor of #25043