gchp/iota

Crash in Vi mode after pressing 'a' followed by 'w'

erszcz opened this issue · 3 comments

erszcz commented

Bug occurs at f35d016, rustc 1.16.0-nightly (c07a6ae77 2017-01-17), macOS 10.12.1. Interesting (or not?) that no other letter pressed after 'a' causes a similar crash. Possibly no other key, but I only tried with letters ;)

$ RUST_BACKTRACE=1 ./target/release/iota --vi
# iota starts in normal mode, I press 'a' directly followed by 'w', iota crashes:
thread 'main' panicked at 'Out of bounds access', /Users/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-mac/build/src/libcore/option.rs:715
stack backtrace:
   1:        0x10263d03c - std::sys::imp::backtrace::tracing::imp::write::h36dcd6719b30e145
   2:        0x10263fbbe - std::panicking::default_hook::{{closure}}::h4ef47a6ed549d2e6
   3:        0x10263f860 - std::panicking::default_hook::hd7b4c7a7e16abb43
   4:        0x102640017 - std::panicking::rust_panic_with_hook::h33761bada49f3713
   5:        0x10263fec4 - std::panicking::begin_panic::h3b15a7df583e5416
   6:        0x10263fde2 - std::panicking::begin_panic_fmt::h4c0c43306d52c68f
   7:        0x10263fd47 - rust_begin_unwind
   8:        0x102662ad0 - core::panicking::panic_fmt::hbd633f652cd3a047
   9:        0x102662b5d - core::option::expect_failed::h6db9910a75455263
  10:        0x1025ab805 - iota::buffer::get_words::hbab139f031bd44ef
  11:        0x1025a9de1 - iota::buffer::Buffer::get_object_index::h040d68a6c7f62bbe
  12:        0x1025ae4a3 - iota::view::View::move_mark::hbf8c49cc666605b7
  13:        0x1025a2dc5 - <iota::editor::Editor<'e, T>>::start::h3865a75248ac2bd3
  14:        0x1025a5a95 - iota::main::h5f520039e2021f17
  15:        0x102640e4a - __rust_maybe_catch_panic
  16:        0x1026403e6 - std::rt::lang_start::h745bea112c3e5e1a
steveslatky commented

Does this always happen for you? When I recreate the bug it panics only when the buffer is completely empty. If there is a single character it does not panic.

I am going to look into this more.

erszcz commented

Having checked again it's just w that causes the crash and, indeed, only when the buffer is empty. What makes some sense, since it ought to jump to the end of the word, but there's not a single word in the buffer yet.

(BTW, I wasn't aware before that a in general is not implemented.)

gchp commented

Just pushed a fix for this. Thanks for the report, and my apologies for the delay in responding.