neovim @0.9.1_1: segmentation fault

[dlamija (Muhammed Ramiza)]

Error: Failed to build neovim: command execution failed .

:info:build /bin/sh: line 1: 22063 Segmentation fault: 11  ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/neovim-0.9.1/src/nvim/po/tojavascript.vim /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/src/nvim/po/nvim.pot /opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/neovim-0.9.1/runtime/optwin.vim
:info:build make[2]: *** [runtime/doc/tags] Error 139
:info:build make[2]: *** Waiting for unfinished jobs....
:info:build make[2]: *** [runtime/pack/dist/opt/matchit/doc/tags] Error 139
:info:build make[2]: *** [runtime/pack/dist/opt/vimball/doc/tags] Error 139
:info:build make[2]: *** [src/nvim/po/nvim.pot] Error 139

[dlamija (Muhammed Ramiza)]

main.log file with error

[mseri (Marcello Seri)]

The same exact error appears on macos sonoma with 0.9.2, not sure if it is better to note it here or open a separate issue:

:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/runtime && /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit
:info:build /bin/sh: line 1:  2516 Segmentation fault: 11  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
:info:build /bin/sh: line 1:  2521 Segmentation fault: 11  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ doc -c quit
:info:build /bin/sh: line 1:  2523 Segmentation fault: 11  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim -u NONE -i NONE -e --headless -c helptags\ ++t\ doc -c quit
:info:build /bin/sh: line 1:  2513 Segmentation fault: 11  ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/neovim-0.9.2/src/nvim/po/tojavascript.vim /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/build/src/nvim/po/nvim.pot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_editors_neovim/neovim/work/neovim-0.9.2/runtime/optwin.vim
:info:build make[2]: *** [runtime/pack/dist/opt/matchit/doc/tags] Error 139
[...]
:info:build make[2]: *** [runtime/pack/dist/opt/vimball/doc/tags] Error 139

[dylanarmstrong (Dylan Armstrong)]

I believe the issue is with luv-luajit from some research this morning. If you use the neovim .deps copy of libluv then it will actually compile correctly. I am looking into this more at the moment.

To duplicate this issue outside of MacPorts:

git clone https://github.com/neovim/neovim.git
cd neovim
git checkout v0.9.2
make deps
mkdir build
cd build
cmake -DLIBLUV_INCLUDE_DIR=/opt/local/include -DLIBLUV_LIBRARY=/opt/local/lib/libluv.dylib ..
make

This should fail with the following

[ 92%] Generating nvim.pot
LuaJIT ASSERT lj_api.c:52: index2adr: calling frame is not a C function
/bin/sh: line 1: 85788 Abort trap: 6           ../../../bin/nvim -u NONE -i NONE -n --headless --cmd "set cpo+=+" -S /Users/dylan/tmp/nv/neovim/src/nvim/po/tojavascript.vim /Users/dylan/tmp/nv/neovim/build/src/nvim/po/nvim.pot /Users/dylan/tmp/nv/neovim/runtime/optwin.vim
make[2]: *** [src/nvim/po/nvim.pot] Error 134
make[1]: *** [src/nvim/po/CMakeFiles/translations.dir/all] Error 2
make: *** [all] Error 2

[frivoal (Florian Rivoal)]

As far as I can tell, I'm running into the same issue.

[helmling]

Same issue here on Sonoma. Tried fix mention in #66077 without success.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicates #68418 and #68419.

[mseri (Marcello Seri)]

nvim 0.9.4 recently released also fails in the same way if I update the portfile. I was not able to make it compile, even following the fix mentioned above (on macos sonoma ARM)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #68537.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #68551.

[jpeeler (Jeff Peeler)]

Neovim seems to track the luajit v2.1 branch closely as it's fully up to date at the time of writing this:

​https://github.com/neovim/neovim/blob/15983cf2c64c527fc13681925d0d00c070c30640/cmake.deps/deps.txt#L7C53-L7C93

​https://github.com/LuaJIT/LuaJIT/commit/e826d0c101d750fac8334d71e221c50d8dbe236c

The luajit portfile is using the original 2.1 release, which occurred March 13, 2022.

​https://github.com/LuaJIT/LuaJIT/commit/c4fe76d50cda24f3529604448f80ff14754599dd

​https://github.com/macports/macports-ports/blob/def852c97f119485e40c7f5c463ca1de3f6cd199/lang/luajit/Portfile#L11C35-L11C75

Since luajit is labeled as a beta, can it just be updated? I'm betting that'll fix the build issue.

[jpeeler (Jeff Peeler)]

After reading ​https://github.com/LuaJIT/LuaJIT/issues/563, it seems there are no more releases any more.

[casr (Chris Rawnsley)]

Just noticed this issue after creating: ​https://github.com/macports/macports-ports/pull/21255

I tested that PR on arm64 Monterey and arm64 Ventura and seems okay. Would someone here who is struggling with this issue be able to report back if that PR makes a difference and what OS & arch you tested it on?

[superobertking (robertking)]

Replying to casr:

Just noticed this issue after creating: ​https://github.com/macports/macports-ports/pull/21255

I tested that PR on arm64 Monterey and arm64 Ventura and seems okay. Would someone here who is struggling with this issue be able to report back if that PR makes a difference and what OS & arch you tested it on?

Tested the patch on arm64 Sonoma, but still does not work. Crash log and stack trace remain exactly the same (crashes at libluajit):

(lldb) r
Process 79425 launched: '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_relea
se_tarballs_ports_editors_neovim/neovim/work/build/bin/nvim' (arm64)
Process 79425 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027)
    frame #0: 0x0000000100c9dd00 libluajit-5.1.2.dylib`___lldb_unnamed_symbol511 + 48
libluajit-5.1.2.dylib`___lldb_unnamed_symbol511:
->  0x100c9dd00 <+48>: ldr    x10, [x1, #0x28]
    0x100c9dd04 <+52>: ldr    w11, [x1, #0x34]
    0x100c9dd08 <+56>: and    x9, x11, x9
    0x100c9dd0c <+60>: mov    w11, #0x18
Target 0: (nvim) stopped.
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027)
  * frame #0: 0x0000000100c9dd00 libluajit-5.1.2.dylib`___lldb_unnamed_symbol511 + 48
    frame #1: 0x0000000100ca5e78 libluajit-5.1.2.dylib`lua_rawget + 40
    frame #2: 0x00000001009ac364 libluv.1.dylib`luv_context + 44
    frame #3: 0x00000001009ac42c libluv.1.dylib`luv_set_loop + 24
    frame #4: 0x00000001001c33a0 nvim`nlua_common_vim_init.llvm.12642962753756758266 + 572
    frame #5: 0x00000001001c2188 nvim`nlua_init + 528
    frame #6: 0x00000001001ccda8 nvim`main + 5024
    frame #7: 0x0000000187505058 dyld`start + 2224

Also tried recompiling luajit port with luajit commit 03c31124cc3b521ef54fe398e10fa55660a5057d, which is the ​neovim luajit deps version, but still crashes on my arm64 Sonoma.

[casr (Chris Rawnsley)]

LuaJIT has been bumped to a more recent version ​https://github.com/macports/macports-ports/pull/21322 which may help

[crowell (Jeffrey Crowell)]

log after LuaJIT update

[crowell (Jeffrey Crowell)]

still fails, uploaded log after updating LuaJIT

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #68722.

[samulip (Samuli P)]

FWIW still fails with new luajit 2.1.1700008891

I don't know what to expect of this issue and do not really understand the cause or even the factors leading to the failure.

Building neovim from a Github release 0.9.4 outside macports worked for me.

It was not fully straightforward when there was faffing around with options to make/cmake (-DLIBLUV_INCLUDE_DIR=/opt/local/include -DLIBLUV_LIBRARY=/opt/local/lib/libluv.dylib) but at least there is a working editor for me now

[wryfi]

On an existing machine, upgrading to neovim 0.9.4 worked without a hitch. On my brand new machine, I'm hosed like everyone else. The only obvious difference I see is a couple of older, deactivated luajit ports installed, otherwise the lua packages/environment look identical as far as I can tell.

> port installed | grep lua
  lua @5.3.6_3 (active)
  lua-luarocks @3.9.2_0 (active)
  lua51 @5.1.5_9 (active)
  lua51-lpeg @1.1.0_0 (active)
  lua51-mpack @1.0.9_0 (active)
  lua53 @5.3.6_3 (active)
  lua53-luarocks @3.9.2_0 (active)
  luajit @2.1.0-beta3_6
  luajit @2.1.1699553127_0
  luajit @2.1.1700008891_0 (active)
  luv-luajit @1.45.0-0_0 (active)

[TheKevJames (Kevin James)]

Tried my hand at narrowing down the possible dependency issues here. Following along with [upstream's list](​https://github.com/neovim/neovim/blob/v0.9.4/cmake.deps/CMakeLists.txt#L135-L199), I did the following:

• updated unibilium and luajit ports to those specific commit hashes (note: our luajit is actually much *newer* than theirs!)
• bumped libuv and lua51-mpack ports to match the pinned versions
• added a new port lua51-compat53, though I used v0.11 (upstream has some missing rockspec files for v0.9 and v1.0)
• swapped msgpack to msgpack-c in our deps (irrelevant, since the former depends on the latter anyway, but including for completion here)

Still no dice.

If anyone is interested in continuing this thread, I've got the dependency updates on a branch [here](​https://github.com/TheKevJames/macports-ports/branches/all?query=kjames%2F&lastTab=overview). Remaining things I noticed about dependency mismatches but have not yet tested:

• our gettext is 0.21.1, theirs is 0.20.1
• our libiconv is 1.17, theirs is 1.15
• my lua-compat53 portfile was 0.11, theirs is 0.9
• tree-sitter-c, tree-sitter-lua, tree-sitter-query, tree-sitter-vim, and tree-sitter-vimdoc are used upstream but not for us
• the lua-luarocks version we use via the portgroup seems to pull in lua53-luarocks, rather than building via lua51

[jpeeler (Jeff Peeler)]

I took comment:20 one step further and recompiled luajit in ​debug mode:

$ lldb --file bin/nvim
(lldb) target create "bin/nvim"
Current executable set to '/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/bin/nvim' (arm64).
(lldb) r
Process 81514 launched: '/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_editors_neovim/neovim/work/build/bin/nvim' (arm64)
Process 81514 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027)
    frame #0: 0x0000000100cc5b38 libluajit-5.1.2.dylib`lj_tab_get + 48
libluajit-5.1.2.dylib`lj_tab_get:
->  0x100cc5b38 <+48>: ldr    x10, [x1, #0x28]
    0x100cc5b3c <+52>: ldr    w11, [x1, #0x34]
    0x100cc5b40 <+56>: and    x9, x11, x9
    0x100cc5b44 <+60>: mov    w11, #0x18
Target 0: (nvim) stopped.

debug libluajit:

$ nm -U /opt/local/lib/libluajit-5.1.dylib | grep tab_get
0000000000009b08 t _lj_tab_get
0000000000009aa4 t _lj_tab_getinth

$ nm -U /opt/local/lib/libluajit-5.1.a | grep tab_get
0000000000001ee8 T _lj_tab_get
0000000000001e84 T _lj_tab_getinth

neovim build from github:

$ nm -U usr/lib/libluajit-5.1.a | grep tab_get
0000000000001028 T _lj_tab_get
0000000000000f88 T _lj_tab_getinth
0000000000000fec T _lj_tab_getstr

I assume if luajit is working as expected the missing symbol above will be resolved. Not sure where to go from here though.

[echesakov (Egor Chesakov)]

I think the issue is due to two conflicting definitions of macro LUA_REGISTRYINDEX used by luv-luajit and luajit ports.

The macro definition seems to change between 5.1 and 5.3 versions of Lua language:

find /opt/local/include -name 'lua\.h' | xargs grep 'define LUA_REGISTRYINDEX'
/opt/local/include/lua5.1/lua.h:#define LUA_REGISTRYINDEX	(-10000)
/opt/local/include/luajit-2.1/lua.h:#define LUA_REGISTRYINDEX	(-10000)
/opt/local/include/lua5.3/lua.h:#define LUA_REGISTRYINDEX	(-LUAI_MAXSTACK - 1000)
/opt/local/include/lua.h:#define LUA_REGISTRYINDEX	(-LUAI_MAXSTACK - 1000)

When port luv-luajit and, file luv.c in particular, is compiled it picks up the definition from /opt/local/include/lua.h (provided by port lua).

Note -I/opt/local/include used in the following command line:

[ 50%] Building C object CMakeFiles/libluv.dir/src/luv.c.o
/usr/bin/clang -Dlibluv_EXPORTS -I/opt/local/include -I/opt/local/include/luajit-2.1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/deps/lua-compat-5.3/c-api -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -fPIC -MD -MT CMakeFiles/libluv.dir/src/luv.c.o -MF CMakeFiles/libluv.dir/src/luv.c.o.d -o CMakeFiles/libluv.dir/src/luv.c.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/src/luv.c

By running preprocessor on luv.c and peeking at the definition of luv_context function:

cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/build"

/usr/bin/clang -Dlibluv_EXPORTS -I/opt/local/include -I/opt/local/include/luajit-2.1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/deps/lua-compat-5.3/c-api -pipe -Os -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -mmacosx-version-min=14.0 -fPIC -MD -MT CMakeFiles/libluv.dir/src/luv.c.o -MF CMakeFiles/libluv.dir/src/luv.c.o.d -o - -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_luv/luv-luajit/work/luv-1.45.0-0/src/luv.c -E | awk '/extern luv_ctx_t\* luv_context\(lua_State\* L\) {/','/lua_type/'

extern luv_ctx_t* luv_context(lua_State* L) {
  luv_ctx_t* ctx;
  lua_pushstring(L, luv_ctx_key);
  lua_rawget(L, (-1000000 - 1000));
  if ((lua_type(L, (-1)) == 0)) {

it can be seen that the macro expands to (-1000000 - 1000).

However, port luajit (that provides libluajit-5.1.2.dylib) and ljamalg.c are compiled against its own version of lua.h.

By running preprocessor on ljamalg.c and peeking at the definition of index2adr function (when the segmentation fault occurs):

cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_luajit/luajit/work/LuaJIT-43d0a19158ceabaa51b0462c1ebc97612b420a2e/src

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_luajit/luajit/work/compwrap/cc/usr/bin/clang  -O2 -fomit-frame-pointer -Wall  -Os -DLUAJIT_ENABLE_LUA52COMPAT -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U_FORTIFY_SOURCE  -DLUA_ROOT=\"/opt/local\" -DLUA_MULTILIB=\"lib\" -fno-stack-protector -DLUAJIT_UNWIND_EXTERNAL   -E -o - ljamalg.c | awk '/static TValue \*index2adr\(/,/} else {/'

static TValue *index2adr(lua_State *L, int idx)
{
  if (idx > 0) {
    TValue *o = L->base + (idx - 1);
    return o < L->top ? o : (&(((global_State *)(void *)(L->glref).ptr64))->nilnode.val);
  } else if (idx > (-10000)) {
    ((void)L);

    return L->top + idx;
  } else if (idx == (-10002)) {
    TValue *o = &(((global_State *)(void *)(L->glref).ptr64))->tmptv;
    settabV(L, o, ((GCtab *)((GCobj *)((L->env)).gcptr64)));
    return o;
  } else if (idx == (-10000)) {
    return (&(((global_State *)(void *)(L->glref).ptr64))->registrytv);
  } else

it can be seen that the macro expands to (-10000).

The segmentation fault occurs

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x800000000027)
  * frame #0: 0x0000000100c9db38 libluajit-5.1.2.dylib`___lldb_unnamed_symbol507 + 48
    frame #1: 0x0000000100ca5ce8 libluajit-5.1.2.dylib`lua_rawget + 40
    frame #2: 0x00000001009ac364 libluv.1.dylib`luv_context + 44
    frame #3: 0x00000001009ac42c libluv.1.dylib`luv_set_loop + 24
    frame #4: 0x00000001001c33a0 nvim`nlua_common_vim_init.llvm.13061164706051272520 + 572
    frame #5: 0x00000001001c2188 nvim`nlua_init + 528
    frame #6: 0x00000001001ccda8 nvim`main + 5024
    frame #7: 0x00000001889150e0 dyld`start + 2360

due to this mismatch since when executing index2adr (___lldb_unnamed_symbol507 in bt output) instead of taking else if (idx == LUA_REGISTRYINDEX) branch the code path go to the else branch:

static TValue *index2adr(lua_State *L, int idx)
{
  if (idx > 0) {
    TValue *o = L->base + (idx - 1);
    return o < L->top ? o : niltv(L);
  } else if (idx > LUA_REGISTRYINDEX) {
    lj_checkapi(idx != 0 && -idx <= L->top - L->base,
		"bad stack slot %d", idx);
    return L->top + idx;
  } else if (idx == LUA_GLOBALSINDEX) {
    TValue *o = &G(L)->tmptv;
    settabV(L, o, tabref(L->env));
    return o;
  } else if (idx == LUA_REGISTRYINDEX) {
    return registry(L);
  } else {
    GCfunc *fn = curr_func(L);
    lj_checkapi(fn->c.gct == ~LJ_TFUNC && !isluafunc(fn),
		"calling frame is not a C function");
    if (idx == LUA_ENVIRONINDEX) {
      TValue *o = &G(L)->tmptv;
      settabV(L, o, tabref(fn->c.env));
      return o;
    } else {
      idx = LUA_GLOBALSINDEX - idx;
      return idx <= fn->c.nupvalues ? &fn->c.upvalue[idx-1] : niltv(L);
    }
  }
}

By uninstalling lua port (need to be forced since lua-luarocks still depends on lua) and re-installing luv-luajit port I could make the installation of neovim succeed.

While looking into this, I also noticed that lua51-lpeg pulls down both lua51 and lua-luarocks (which in turns pulls down lua) and I am not sure if this looks right:

port rdeps lua51-lpeg
The following ports are dependencies of lua51-lpeg @1.1.0_0:
  lua-luarocks
    lua
      readline
        ncurses
    lua53-luarocks
      lua53
  lua51

Uninstalling lua is, obviously, not a proper solution here but I wanted to share this in case someone more familiar with MacPorts dependencies would able to pick it up from here.

[l2dy (Zero King)]

Replying to echesakov:

I think the issue is due to two conflicting definitions of macro LUA_REGISTRYINDEX used by luv-luajit and luajit ports.

If only luv.c needs to be built against LuaJIT headers, update to luv-luajit @1.45.0-0_1 (_1 means revision 1) and try again.

[echesakov (Egor Chesakov)]

Replying to l2dy:

If only luv.c needs to be built against LuaJIT headers, update to luv-luajit @1.45.0-0_1 (_1 means revision 1) and try again.

This fixed the issue for me. Thank you for updating the port.

[superobertking (robertking)]

Can confirm it works now! Thanks everyone for the debugging and updating effort!

[l2dy (Zero King)]

Thanks for confirming the fix!