khvzak
commented
3 weeks ago Is it possible that you loaded lua-json5 module from non-main coroutine (lua state)? E.g. somewhere inside a function rather than on top level during neovim loading.
Closed jedrzejboczar closed 2 weeks ago
khvzak
commented
3 weeks ago Is it possible that you loaded lua-json5 module from non-main coroutine (lua state)? E.g. somewhere inside a function rather than on top level during neovim loading.
jedrzejboczar
commented
3 weeks ago I am not sure but this might be the case. lua-json5 is being lazy-loaded when executing a neovim key mapping callback.
The exact execution is:
lua-json5 is lazy-loaded (as dependency of another package but I guess it's not relevant here)lua-json5 is used to parse itThe lazy loading is done by https://github.com/folke/lazy.nvim plugin manager, and I don't think it does the loading in a coroutine. When I put print(debug.traceback('loading lua-json5')) inside lazy.nvim's config handler for lua-json5 I can see the following:
loading lua-json5
stack traceback:
~/.config/nvim/lua/jb/plugins/dap/init.lua:321: in function 'config'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:376: in function <...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:374>
[C]: in function 'xpcall'
.../.local/share/nvim/lazy/lazy.nvim/lua/lazy/core/util.lua:135: in function 'try'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:391: in function 'config'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:358: in function '_load'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:197: in function 'load'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:352: in function <...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:351>
[C]: in function 'xpcall'
.../.local/share/nvim/lazy/lazy.nvim/lua/lazy/core/util.lua:135: in function 'try'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:351: in function '_load'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:197: in function 'load'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:539: in function 'auto_load'
...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:560: in function <...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:548>
[C]: in function 'require'
~/.config/nvim/lua/jb/plugins/telescope/pickers.lua:898: in function 'get_dap_configurations'
~/.config/nvim/lua/jb/plugins/telescope/pickers.lua:936: in function <~/.config/nvim/lua/jb/plugins/telescope/pickers.lua:933>So it looks like the call is not rooted in init.lua but I'd assume it's still running on the main coroutine?
Note that I don't get segfault in most cases, for some reason it only happens sometimes, so it might be that the call stack is different when the segfault happens.
Anyway, I'll try to disable lazy-loading of lua-json5 and see if it helps.
khvzak
commented
3 weeks ago On first load, mlua tries to obtain a main state (main coroutine) from Lua. Lua 5.1/JIT don't have a method for that (Lua 5.2+ has) so instead current coroutine saved and reused.
It's possible that after lazy loading from non-main coroutine, it was destroyed and then reused to obtain allocation handler. Otherwise I don't see any other reasons why g->allocd; refers to invalid address.
I can change this behaviour to always use current (active) Lua thread instead.
it calls my Lua handler (I suppose this is called from main coroutine?)
I'm not sure about this. From the backtrace we can see that coroutine used to call MemoryState::get (0x733f6f876380) is different from the coroutine where module was loaded (0x733f69ec1290) and marked as main.
jedrzejboczar
commented
3 weeks ago Ok, thanks for the analysis. I will report back if the segfault happens again now, when I removed lazy-loading of lua-json5. Had no problems yet, but I'd wait a few days.
khvzak
commented
2 weeks ago Please reopen if the problem still exists. I pushed a fix already
Hi, I am trying to track down a segfault that happens when I'm using lua-json5 plugin from Neovim. I previously described the bug here https://github.com/Joakker/lua-json5/issues/5, but I am now thinking that maybe this is something with mlua itself.
Here is my latest stack traceback with debug symbols enabled:
And with variable values
``` (gdb) bt -full -frame-arguments all -entry-values if-needed #0 0x0000733f6f76314d in lua_getallocf (L=0x733f69ec1290, ud=0x7ffe219b48b0) at /usr/src/debug/luajit/LuaJIT-97813fb924edf822455f91a5fbbdfdb349e5984f/src/lj_api.c:1309 g = 0x33 #1 0x0000733f694fe9a9 in mlua::memory::MemoryState::get () at /home/jb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/mlua-0.9.7/src/memory.rs:30 mem_state = 0x0 state = 0x733f69ec1290 #2 mlua::lua::Lua::unlikely_memory_error (self=It looks like it fails on
if (ud) *ud = g->allocd;here:The exact address is a little different than in https://github.com/Joakker/lua-json5/issues/5#issuecomment-2426277452, but it looks is an offset into
global_Statewhich itself has address near 0:I'm also adding the contnet of
selfinsidemlua::lua::Lua::create_table_from:Do you have any idea what might be the problem? Or is it not related to mlua but something else up the stack?