-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash: vim.uv.walk #25043
Comments
All versions of neovim (that I have) have a |
Libluvs wrapper around uv_walk assumes that libluv (the lua bindings) make exclusive use of the uv event loop. This leads to a crash in nvim as libluv then cannot understand handles that is owned by nvim core, not libluv. This could be fixed in libluv at the price of making the implementation more complicated. Alternatively, we could change So I am curious what the usecase of using |
My intent was to iterate through the existing timers and methodically delete them, so as to find which of my plugins is periodically running While tinkering with this idea I had imagined / hoped for a |
Would you kindly point out the relevant code? The function I saw takes the event loop as the first argument, so I had expected a method ( |
It's luv_walk in src/loop.c. libluv keeps track of one uv event loop per lua thread. Indepdendent luv event loops are possible, but they must then run in a separate thread (
Debugging the event loop is a relevant usecase. But it is going to require some cooperation from nvim core. Such an interface would ideally show and identify uv handles regardless if they come from libluv or nvim core (often wrappers for jobs and timers for vimscript and also RPC channels). |
Is the nvim-core loop exposed to lua at all, currently? The convention of one-loop-per-lua seems baked into luv pretty deep... are you picturing a major revision to luv or would you not use it for this? |
No not at all. I'm just saying implementing the debugging functionality you want is going to be a bit more involved than just an isolated change to just |
On Fri, Sep 8, 2023, 3:52 PM bfredl ***@***.***> wrote:
The convention of one-loop-per-lua seems baked into luv pretty deep... are
you picturing a major revision to luv or would you not use it for this?
No not at all. I'm just saying implementing the *debugging* functionality
you want is going to be a bit more involved than just an isolated change to
just vim.uv.walk . It is definitely something worth doing and a welcome
contribution, I just want to be clear upfront with the scope of the effort
needed.
—
Reply to this email directly, view it on GitHub
<#25043 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE4KSEQVMVPRYGCPIO5O3LXZOAPTANCNFSM6AAAAAA4POFTEI>
.
You are receiving this because you authored the thread.
Thanks. My question was about the nature of such a hypothetical
contribution. Could you outline what you'd expect, in broad strokes?
To my understanding, this would need either:
A. a major revision to luv to allow it to represent/interact with more
than one loop per lua vm
B. this bit of neovim API wouldn't use luv, and reach more directly to
libuv
C. a third option that you can think of but I can't
My money is on option C :)
… Message ID: ***@***.***>
|
Problem
Using
vim.loop.walk
in any way results in nvim crashing with a segmentation fault (same forvim.uv.walk
).Steps to reproduce
I got that particular message from v0.4.4. Newer versions crash silently (seems worse, to me).
Expected behavior
Print
ohai
a bunch of times.Neovim version (nvim -v)
NVIM v0.10.0-dev-1046+g3afbf4745, NVIM v0.9.1, NVIM v0.4.4
Vim (not Nvim) behaves the same?
n/a
Operating system/version
$ uname -a Linux penguin 5.15.117-19679-g172023e664f7 #1 SMP PREEMPT Fri Aug 18 18:07:47 PDT 2023 x86_64 GNU/Linux
Terminal name/version
hterm
$TERM environment variable
n/a
Installation
source, brew, debian (respectively)
The text was updated successfully, but these errors were encountered: