Issues with workspaces

[robamu]

I have issues with workspaces which might be related to this plugin. More specifically, if I open neovim inside my workspace folder, everything works as expected. However, when I open neovim in a subfolder of that workspace and try to run tests or open the test tree with neotest, neovim crashes. Is this a known issue? I have had trouble to trace this to a single function, I tried reading the crash dumps of neovim, but it does not contain any useful information. I think the best behaviour, if that is possible, would also be to only run the tests of that subpackage in the workspace, if I open neovim in that subfolder.

OS: Ubuntu 22.04
neovim version: v0.9.4

[rouge8]

That is not expected. Can you reproduce with any of the files in https://github.com/rouge8/neotest-rust/tree/main/tests/data/workspace ? Otherwise, can you link to a project that does reproduce?

[robamu]

I can actually reproduce this by opening nvim in a subfolder of the workspace you linked. It's probably the same issue.

Core dump:

data/workspace/with_integration_tests on  main is 📦 v0.1.0 via 🦀 v1.76.0 took 6s
❯ coredumpctl -1 gdb
           PID: 11104 (nvim)
           UID: 1000 (rmueller)
           GID: 1000 (rmueller)
        Signal: 6 (ABRT)
     Timestamp: Mon 2024-02-26 23:43:32 CET (2s ago)
  Command Line: nvim --embed
    Executable: /usr/local/bin/nvim
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-b98d8579-5d99-433e-8544-8cdac0d57194.scope
          Unit: user@1000.service
     User Unit: vte-spawn-b98d8579-5d99-433e-8544-8cdac0d57194.scope
         Slice: user-1000.slice
     Owner UID: 1000 (rmueller)
       Boot ID: a39430be687c470e8c392b2c983bef0d
    Machine ID: c2dcdeb02ed0426ea86eac6329555123
      Hostname: power-pinguinn
       Storage: /var/lib/systemd/coredump/core.nvim.1000.a39430be687c470e8c392b2c983bef0d.11104.1708987412000000.zst (present)
     Disk Size: 4.5M
       Message: Process 11104 (nvim) of user 1000 dumped core.

                Found module /home/rmueller/.local/share/nvim/site/pack/packer/start/nvim-treesitter/parser/rust.so with build-id: f3869be0b9fbde1fd26dbfa279f2d21b9abc38be
                Found module /home/rmueller/.local/share/nvim/site/pack/packer/start/telescope-fzf-native.nvim/build/libfzf.so with build-id: 6afc4a98b75946b4d1acd6f60984c53ec723acdb
                Found module linux-vdso.so.1 with build-id: 41041f17dc6e6f3c185ad11e19ef34b97e16c369
                Found module ld-linux-x86-64.so.2 with build-id: 15921ea631d9f36502d20459c43e5c85b7d6ab76
                Found module libc.so.6 with build-id: c289da5071a3399de893d2af81d6a30c62646e1e
                Found module libgcc_s.so.1 with build-id: e3a44e0da9c6e835d293ed8fd2882b4c4a87130c
                Found module libm.so.6 with build-id: a88ef0199bd5e742ebd0c359edf5cb2be0ec08b5
                Found module nvim with build-id: 804d3045bc1853e2e3c315edda93d62f7ebcdc7e
                Stack trace of thread 11104:
                #0  0x00007f29a9a969fc __pthread_kill_implementation (libc.so.6 + 0x969fc)
                #1  0x00007f29a9a42476 __GI_raise (libc.so.6 + 0x42476)
                #2  0x00007f29a9a287f3 __GI_abort (libc.so.6 + 0x287f3)
                #3  0x000056500c907b44 loop_uv_run (nvim + 0x159b44)
                #4  0x000056500c9087da loop_poll_events (nvim + 0x15a7da)
                #5  0x000056500c96da08 nlua_wait (nvim + 0x1bfa08)
                #6  0x000056500cb28906 lj_BC_FUNCC (nvim + 0x37a906)
                #7  0x000056500cb2973c lj_ff_coroutine_resume (nvim + 0x37b73c)
                #8  0x000056500cb14bec lua_pcall (nvim + 0x366bec)
                #9  0x000056500c96664e nlua_pcall (nvim + 0x1b864e)
                #10 0x000056500c96d2dd nlua_luv_cfpcall (nvim + 0x1bf2dd)
                #11 0x000056500cabfdd5 luv_fs_cb (nvim + 0x311dd5)
                #12 0x000056500cb7191d uv__work_done (nvim + 0x3c391d)
                #13 0x000056500cb7582b uv__async_io (nvim + 0x3c782b)
                #14 0x000056500cb87d43 uv__io_poll (nvim + 0x3d9d43)
                #15 0x000056500cb76426 uv_run (nvim + 0x3c8426)
                #16 0x000056500c907b6e loop_uv_run (nvim + 0x159b6e)
                #17 0x000056500c9087da loop_poll_events (nvim + 0x15a7da)
                #18 0x000056500c9e0d56 inbuf_poll (nvim + 0x232d56)
                #19 0x000056500c9e1247 os_inchar (nvim + 0x233247)
                #20 0x000056500ca55339 state_enter (nvim + 0x2a7339)
                #21 0x000056500c9b361a normal_enter (nvim + 0x20561a)
                #22 0x000056500c841326 main (nvim + 0x93326)
                #23 0x00007f29a9a29d90 __libc_start_call_main (libc.so.6 + 0x29d90)
                #24 0x00007f29a9a29e40 __libc_start_main_impl (libc.so.6 + 0x29e40)
                #25 0x000056500c83c8c5 _start (nvim + 0x8e8c5)

                Stack trace of thread 11267:
                #0  0x00007f29a9a91117 __futex_abstimed_wait_common64 (libc.so.6 + 0x91117)
                #1  0x00007f29a9a93a41 __pthread_cond_wait_common (libc.so.6 + 0x93a41)
                #2  0x000056500cb832cd uv_cond_wait (nvim + 0x3d52cd)
                #3  0x000056500cb71302 worker (nvim + 0x3c3302)
                #4  0x00007f29a9a94ac3 start_thread (libc.so.6 + 0x94ac3)
                #5  0x00007f29a9b26850 __clone3 (libc.so.6 + 0x126850)

                Stack trace of thread 11269:
                #0  0x00007f29a9a91117 __futex_abstimed_wait_common64 (libc.so.6 + 0x91117)
                #1  0x00007f29a9a93a41 __pthread_cond_wait_common (libc.so.6 + 0x93a41)
                #2  0x000056500cb832cd uv_cond_wait (nvim + 0x3d52cd)
                #3  0x000056500cb71302 worker (nvim + 0x3c3302)
                #4  0x00007f29a9a94ac3 start_thread (libc.so.6 + 0x94ac3)
                #5  0x00007f29a9b26850 __clone3 (libc.so.6 + 0x126850)

                Stack trace of thread 11268:
                #0  0x00007f29a9a91117 __futex_abstimed_wait_common64 (libc.so.6 + 0x91117)
                #1  0x00007f29a9a93a41 __pthread_cond_wait_common (libc.so.6 + 0x93a41)
                #2  0x000056500cb832cd uv_cond_wait (nvim + 0x3d52cd)
                #3  0x000056500cb71302 worker (nvim + 0x3c3302)
                #4  0x00007f29a9a94ac3 start_thread (libc.so.6 + 0x94ac3)
                #5  0x00007f29a9b26850 __clone3 (libc.so.6 + 0x126850)

                Stack trace of thread 11106:
                #0  0x0000000000000000 n/a (n/a + 0x0)

I reproduced the error above by opening nvim inside with_integration_test and then trying to run a test inside some file. I can also reproduce a crash by simply opening the test tree window of neotest. When opening neovim inside the workspace itself, everything works without issues.

[duncanam]

+1 on this issue. Works great on nornal projects, but if I open nvim inside a workspace (e.g. Rust monorepo) and try and run testing for one package, immediate crash.

[rouge8]

I'm not sure how to debug this. It works fine for me with nvim 0.9.5 on macOS.

[duncanam]

I was able to figure out that if I open neovim inside one of the subcrates, it crashes. If i open neovim in the monorepo/workspace base, no crash. Puzzling, but this at least gives me a hacky workaround for the time being.

[robamu]

It's interesting to know that this only occurs on Linux. I might poke around a bit more. Are you interested in some other specific information or do you have some ideas where I could start debugging in the neotest or neotest-rust lua code based on the crash dump above?

[rouge8]

I have no idea where to go with this, so whatever you can come up with would be great!

[robamu]

I tried to trace this in neotest, but I am a little lost now.. It's a lot of code, and I am not sure where to look because this is just a sudden full crash without any error information or any useful context information in the crash dump.. For now, the best way for anyone encountering this is to only open neovim in the top level workspace folder.

[jsiefer]

Similar issue, fails for me in cargo_metadata::__call when running the job command for cargo metadata.

[connorgmeehan]

@robamu I have the same issue on MacOS (intel). If you tested on an AMD 64 macbook then it be an architecture issue rather than platform issue?

[ckoehler]

I am also seeing a crash on an M1 Mac. I tried to reproduce with Neovim nightly and debug symbols, from Nix, but it doesn't crash there, so I wonder if the latest Neovim has this fixed.
Here's the backtrace for nvim 0.9.5:

* thread #1
  * frame #0: 0x0000000183816a60 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x000000018384ec20 libsystem_pthread.dylib`pthread_kill + 288
    frame #2: 0x000000018375ba20 libsystem_c.dylib`abort + 180
    frame #3: 0x0000000104b9e368 nvim`loop_uv_run + 204
    frame #4: 0x0000000104a58f00 nvim`nlua_wait.llvm.12217083546382456335 + 660
    frame #5: 0x00000001053fda0c libluajit-5.1.2.dylib`___lldb_unnamed_symbol344 + 44
    frame #6: 0x00000001053fe650 libluajit-5.1.2.dylib`___lldb_unnamed_symbol405 + 156
    frame #7: 0x000000010540a5b0 libluajit-5.1.2.dylib`lua_pcall + 148
    frame #8: 0x0000000104aaf18c nvim`nlua_pcall.llvm.12217083546382456335 + 120
    frame #9: 0x0000000104ab0bf4 nvim`nlua_luv_cfpcall.llvm.12217083546382456335 + 100
    frame #10: 0x0000000105261acc libluv.1.dylib`luv_fs_cb + 204
    frame #11: 0x00000001053b2dfc libuv.1.dylib`uv__work_done + 184
    frame #12: 0x00000001053b64a8 libuv.1.dylib`uv__async_io + 268
    frame #13: 0x00000001053c6164 libuv.1.dylib`uv__io_poll + 1408
    frame #14: 0x00000001053b693c libuv.1.dylib`uv_run + 272
    frame #15: 0x0000000104b9e324 nvim`loop_uv_run + 136
    frame #16: 0x0000000104aeb0d4 nvim`os_breakcheck + 64
    frame #17: 0x0000000104b1c708 nvim`state_handle_k_event + 152
    frame #18: 0x0000000104a361fc nvim`nv_event.llvm.3538084630391803091 + 60
    frame #19: 0x0000000104b9cf64 nvim`normal_execute.llvm.3538084630391803091 + 4748
    frame #20: 0x0000000104c184e4 nvim`state_enter + 356
    frame #21: 0x0000000104ab4278 nvim`main + 9644
    frame #22: 0x00000001834c60e0 dyld`start + 2360

EDIT: Using the default neovim package from Nix (not nightly), this crashes as well, which makes me think this is/will be fixed with a new version of neovim. 🤷‍♂️