Open remexre opened 1 day ago
So your fix is to just disable the cpu time??
Not a fix, a "debugging patch" -- it seems that it's pointing at that block as being related to the problem. The time_t
definition, I can at least verify as being ABI-incorrect, so it could be the cause of the memory corruption, but I think there's something else there too (since just changing it to long long
is insufficient to fix the segfault.)
Did you check docs and existing issues?
Neovim version (nvim -v)
v0.11.0-dev-1201+g0e2f92ed79
Operating system/version
Alpine Linux v3.14
Describe the bug
(Note: this reproduces on a wide variety of Neovim commits, and on later versions of Alpine and on Gentoo with a musl profile.)
lazy.nvim segfaults on i686-musl systems. It seems that this can be fixed with the following patch:
The
typedef long time_t;
is certainly incorrect here --long
isint32_t
on i686, buttime_t
isint64_t
.(This is insufficient to fix the segfault, but it's at least an easy thing to fix.)
FWIW, an example stack trace on segfault is:
How exactly we get to
gc_sweep
differs, but the trace always ends in those same frames#0-#3
.Steps To Reproduce
Be on an i686-musl platform. (The
muslcc/i686:i686-linux-musl
Docker container is sufficient.)Use the following
init.lua
:Open
nvim ~/.config/nvim/init.lua
(or another not-tiny file; if it doesn't repro, open another/larger file)Get a segfault
Expected Behavior
Don't segfault
Repro