[Bug] Netrw crashes gnvim about gnvim HOT 31 CLOSED

...there shouldn't be a need to handle it in gnvim, right?

It depends. Some people are seeing this bug and, without knowing the details of it, might drive them away from gnvim. This is indeed a bug that I would not want to fix in gnvim, as I'm not completely sure of the side effects - if there are any. If there are side effects, those would go unnoticed for long time.

I'm not sure if the origin of neovim/neovim#10000 are known. I'd imagine that if it was, it would be fixed by now (thus any feedback for it probably is appreciated).

from gnvim.

am in the process of building neovim 0.4.3 (and shipping package updates to my distro) 😄

from gnvim.

Actually, it is now occurring even when running gnvim from the terminal.

Error Message

thread 'main' panicked at 'byte index 2 is out of bounds of ``', src/libcore/str/mod.rs:2010:9
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: g_main_context_dispatch
  15: <unknown>
  16: g_main_context_iteration
  17: g_application_run
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: __libc_start_main
  26: <unknown>

from gnvim.

Try master, should be fixed: #24

from gnvim.

Sadly I run into the same issue where I works when launching from the terminal but not outside it.

from gnvim.

One reason could be having two versions of gnvim installed, the one launched outside of terminal being outdated.

from gnvim.

That would make sense. However, whenever I run sudo make uninstall, I can no longer start up gnvim from either place. When I do sudo make install, then both begin working again and the same issue persists.

from gnvim.

Can you do RUST_BACKTRACE=1 cargo run? cargo run runs the debug build which would give more information.

from gnvim.

I managed to reproduce this issue and it looks like this is related to #29, which in turn is caused by a bug in neovim. Related neovim issue: neovim/neovim#10000.

Marking as duplicate for now.

from gnvim.

You seem to have already handled it, but for the sake of thoroughness, when doing RUST_BACKTRACE=1 cargo run, I have no issues running :Explore. I think this is because it is running from the terminal.

Here is the output after running and executing :Explore:

Finished dev [unoptimized + debuginfo] target(s) in 2m 19s
Running `target/debug/gnvim`

from gnvim.

For me, I had to navigate to home dir on netrw to reproduce the problem.

from gnvim.

Ah, I see. The reason I was noticing the issue when running outside of the terminal was because Netrw was opening the home directory and not anything special about running it outside the terminal. When I run outside the terminal and then cd into a directory other than my home, it works as expected.

When I run RUST_BACKTRACE=1 cargo run and then navigate Netrw to the home directory, I get the following output:

thread 'main' panicked at 'byte index 2 is out of bounds of ``', src/libcore/str/mod.rs:2010:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::str::slice_error_fail
   9: core::str::<impl str>::split_at
             at /build/rust/src/rustc-1.34.1-src/src/libcore/str/mod.rs:2462
  10: gnvim::ui::cmdline::CmdlineInput::ensure_cursor_pos
             at src/ui/cmdline.rs:382
  11: gnvim::ui::cmdline::CmdlineInput::set_cursor
             at src/ui/cmdline.rs:375
  12: gnvim::ui::cmdline::CmdlineInput::set_text
             at src/ui/cmdline.rs:294
  13: gnvim::ui::cmdline::Cmdline::show
             at src/ui/cmdline.rs:554
  14: gnvim::ui::ui::handle_redraw_event
             at src/ui/ui.rs:720
  15: gnvim::ui::ui::handle_notify
             at src/ui/ui.rs:410
  16: gnvim::ui::ui::UI::start::{{closure}}::{{closure}}
             at src/ui/ui.rs:346
  17: glib::source::trampoline
             at /home/eli/.cargo/registry/src/github.com-1ecc6299db9ec823/glib-0.6.1/src/source.rs:103
  18: g_main_context_dispatch
  19: <unknown>
  20: g_main_context_iteration
  21: g_application_run
  22: <O as gio::application::ApplicationExtManual>::run
             at /home/eli/.cargo/registry/src/github.com-1ecc6299db9ec823/gio-0.5.1/src/application.rs:23
  23: gnvim::main
             at src/main.rs:155
  24: std::rt::lang_start::{{closure}}
             at /build/rust/src/rustc-1.34.1-src/src/libstd/rt.rs:64
  25: std::panicking::try::do_call
  26: __rust_maybe_catch_panic
  27: std::rt::lang_start_internal
  28: std::rt::lang_start
             at /build/rust/src/rustc-1.34.1-src/src/libstd/rt.rs:64
  29: main
  30: __libc_start_main
  31: _start

from gnvim.

Looking more into it, it is not just my home directory that causes the issue. It seems that any directory which contains symbolic links causes the same issue.

from gnvim.

Looking more into it, it is not just my home directory that causes the issue. It seems that any directory which contains symbolic links causes the same issue.

@bfredl that might help with neovim/neovim#10000

from gnvim.

Interestingly, I can reproduce this, but I'm not sure it's related to Netrw. For reference, I have this in my init.vim:

cmap ,init tabe<Space>~/.config/nvim/init.vim<CR>

to quickly access my Neovim config file. When I type , and then quickly hit the esc key, gnvim crashes (with essentially the same backtrace as elihunter showed above). This will happen if I hit esc at any point in the mapped command before I finish it (e.g. if I type ,t and then hit Escape before the cmdline stops waiting for the rest of the command, gnvim crashes in the same way). Not certain this is related, but wanted to mention it; if anyone can reproduce this (try any command mapped with cmap), I would be interested to know. (As an FYI, I am running neovim nightly, version from a day or so ago.)

from gnvim.

@smolck Interesting, I can reproduce that with any cmap I try.

Backtrace

thread 'main' panicked at 'byte index 2 is out of bounds of ``', src/libcore/str/mod.rs:2010:9
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>
  11: <unknown>
  12: <unknown>
  13: <unknown>
  14: g_main_context_dispatch
  15: <unknown>
  16: g_main_context_iteration
  17: g_application_run
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: __libc_start_main
  26: <unknown>

Versions

gnvim 0.1.3-3-g4f7c547

NVIM v0.3.7
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wconversion -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.3.7/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

from gnvim.

The origin of this issue is this: neovim/neovim#10000.

As a workaround, we could check that the split_at call here is at utf8 character position and if its not, just return. That might or might not have some other side effects and other bugs might go undiscovered.

from gnvim.

@vhakulinen Considering that this is a neovim bug, there shouldn't be a need to handle it in gnvim, right? If this bug goes a long time without being fixed (which, considering how fast Neovim is developed, is hopefully unlikely), maybe we should then workaround it in gnvim (does it hinder workflow enough to make that necessary, though? I've only encountered it a few times, and it hasn't stopped me from using gnvim.).

As a side note, is the fact that an invalid cmdline_show message is sent when using a cmap command and esc something I should mention on neovim/neovim#1000?

from gnvim.

Would you mind trying latest nvim master (just merged) and check if the issue is fixed?

from gnvim.

@bfredl Latest master fixed the problem for me (at least for cmap commands)! (Thanks for such a quick fix!)

from gnvim.

@bfredl Latest master fixed the problem of symlinks for me. Thank you!

from gnvim.

I just installed from master yesterday:

• Ubuntu 18.04
• gnvim 0.1.4-15-g80eb6c0
• nvim v0.3.7

and I'm getting this error still, I've tried opening gnvim in my home directory and I get the following error:

I know you can ignore the Not supported messages but here's the full output:

channi16@ICT0115123:~$ export RUST_BACKTRACE=1
channi16@ICT0115123:~$ gnvim
Unknown highligh property: standout
Not supported option set: arabicshape
Not supported option set: ambiwidth
Not supported option set: emoji
Not supported option set: guifontset
Not supported option set: guifontwide
Not supported option set: showtabline
Not supported option set: termguicolors
Not supported option set: ext_linegrid
Not supported option set: ext_hlstate
Not supported option set: ext_cmdline
Not supported option set: ext_popupmenu
Not supported option set: ext_tabline
Not supported option set: ext_wildmenu
Not supported option set: termguicolors
Not supported option set: termguicolors
Not supported option set: ext_cmdline
Not supported option set: ext_popupmenu
Not supported option set: ext_tabline
Not supported option set: ext_wildmenu
Not supported option set: ext_cmdline
Not supported option set: ext_popupmenu
Not supported option set: ext_tabline
Not supported option set: ext_wildmenu
Not supported option set: ext_cmdline
Not supported option set: ext_popupmenu
Not supported option set: ext_tabline
Not supported option set: ext_wildmenu
Failed to turn input event into nvim key (keyval: 65506)
Failed to turn input event into nvim key (keyval: 65506)
thread 'main' panicked at 'byte index 2 is out of bounds of ``', src/libcore/str/mod.rs:2010:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::str::slice_error_fail
   9: gnvim::ui::cmdline::CmdlineInput::set_cursor
  10: gnvim::ui::cmdline::Cmdline::show
  11: gnvim::ui::ui::handle_redraw_event
  12: gnvim::ui::ui::handle_notify
  13: glib::source::trampoline
  14: g_main_context_dispatch
  15: <unknown>
  16: g_main_context_iteration
  17: g_application_run
  18: <O as gio::application::ApplicationExtManual>::run
  19: gnvim::main
  20: std::rt::lang_start::{{closure}}
  21: std::panicking::try::do_call
  22: __rust_maybe_catch_panic
  23: std::rt::lang_start_internal
  24: main
  25: __libc_start_main
  26: _start

from gnvim.

Ah maybe this is because the fix for neovim/neovim#10000 is in nvim master branch but not released out yet?

Looks like it's planned for v0.4

from gnvim.

Yeah, if you build neovim from master (the nightly release will probably work too), it should work as expected.

from gnvim.

. . . (the nightly release will probably work too) . . .

With neovim-nightly on the AUR this problem is fixed for me, so I can confirm that nightly works.

from gnvim.

So, as far as I understand, this bug is only triggered when executing gnvim from terminal, right?

I could just reproduce this bug with gnvim 0.1.5 started not from terminal. Am I wrong with my expectation that this is only valid for not-from-terminal started gnvim, or shall we reopen this issue?

Edit: And I can only produce this crash when working in the home directory. Strange! (Update on the edit: Can reproduce this outside of $HOME) Still on 0.1.5 though, I'm going to build master now and try to reproduce.

from gnvim.

So, as far as I understand, this bug is only triggered when executing gnvim from terminal, right?

I could just reproduce this bug with gnvim 0.1.5 started not from terminal. Am I wrong with my expectation that this is only valid for not-from-terminal started gnvim, or shall we reopen this issue?

Edit: And I can only produce this crash when working in the home directory. Strange! (Update on the edit: Can reproduce this outside of $HOME) Still on 0.1.5 though, I'm going to build master now and try to reproduce.

@matthiasbeyer You’re still getting this issue then? What is your Neovim version? I believe this was an upstream bug, but it should be fixed now.

from gnvim.

$ nvim -v
NVIM v0.3.8
Build type: Release
LuaJIT 2.1.0-beta3
Compilation:

from gnvim.

I never had a crashing nvim though!

I am currently debugging this: The crash happens at https://github.com/vhakulinen/gnvim/blob/master/src/ui/cmdline.rs#L404 because the index is either out of bounds or not a valid unicode-boundary. I am not sure what the fix is here, but if you guide me I'll submit a patch shortly (if I can fix it).

from gnvim.

I never had a crashing nvim though!

Yes, but I believe the crash was caused by Neovim sending incorrect values over RPC to GNvim (causing it to crash due to assumptions that would normally have been correct if Neovim had sent the correct value). Would you mind downloading the latest Neovim version (v0.4.3) from https://github.com/neovim/neovim/releases and then running GNvim with gnvim --nvim /path/to/nvim/binary and testing if it still crashes?

See #43 (comment).

from gnvim.

Okay, can confirm:

gnvim 1.5.0 + neovim 0.4.3 -> Crash
gnvim master + neovim 0.4.3 -> Seems to work
gnvim patched + neovim 0.3.8 -> Seems to work
gnvim patched + neovim 0.4.3 -> Seems to work

So it looks like this is a bug in gnvim. Patch incoming.

from gnvim.