gchp / iota

A terminal-based text editor written in Rust
MIT License
1.63k stars 81 forks source link

Panic with ./target/iota src/main.rs #15

Closed leonardinius closed 9 years ago

leonardinius commented 9 years ago

Opened by ./target/iota src/main.rs and just did something like Pg-Down, Pg-Down, Enter, Enter, Pg-Down, Pg-Down

Panick

task '<main>' panicked at 'index out of bounds: the len is 21 but the index is 21', src/iota/lib.rs:1
Options:                                                                                             task '<unnamed>' panicked at 'sending on a closed channel', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libstd/comm/mod.rs:555
";                                                                             

Disclaimer: I'm new into Rust ecosystem, so I don't know what details to provide or how to obtain stacktrace et cetera ... If anything I'm wiling to provide you with more details.

abonander commented 9 years ago

Try this:

RUST_BACKTRACE=1 ./target/iota src/main.rs

leonardinius commented 9 years ago

Ok, so I got this

14:     0x7f82bd99f970 - editor::Editor<'e>::start::h641a85ed1d183d9bCqa
15:     0x7f82bd8d8fa0 - main::h2b294bd0df0129dblda
16:     0x7f82bd9c6cc0 - rt::start::closure.32694
17:     0x7f82bd9d39b0 - rust_try_inner
18:     0x7f82bd9d39a0 - rust_try
19:     0x7f82bd9d16f0 - unwind::try::ha36bc8815a761f13pFc
20:     0x7f82bd9d14c0 - task::Task::run::h24525a73fb4c9bb3fOb
21:     0x7f82bd9c6970 - rt::start::h2ae66816f70e2602QHy
22:     0x7f82bd9c68e0 - rt::lang_start::h09857311e158dc649Gy
23:     0x7f82bd8d92c0 - main
24:     0x7f82bcabfdd0 - __libc_start_main
25:     0x7f82bd8d8e00 - <unknown>
26:                0x0 - <unknown>
task '<unnamed>' panicked at 'sending on a closed channel', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libstd/comm/mod.rs:555
stack backtrace:
1:     0x7f82bd9c2c50 - rt::backtrace::imp::write::hf87c140cfcd95fbaBly
2:     0x7f82bd9c5b20 - failure::on_fail::h343c4b97464b676eZNy
3:     0x7f82bd9d3130 - unwind::begin_unwind_inner::hb4b9831d2f5e86936Qc
4:     0x7f82bd98b440 - unwind::begin_unwind::h6377330880198875041
5:     0x7f82bd9a78b0 - comm::Sender<T>::send::h4473599734853009076
6:     0x7f82bd9a7770 - editor::Editor<'e>::event_loop::closure.4440
7:     0x7f82bd9d1620 - task::Task::spawn::closure.5765
8:     0x7f82bd9d39b0 - rust_try_inner
9:     0x7f82bd9d39a0 - rust_try
10:     0x7f82bd9d16f0 - unwind::try::ha36bc8815a761f13pFc
11:     0x7f82bd9d14c0 - task::Task::run::h24525a73fb4c9bb3fOb
12:     0x7f82bd9d10b0 - task::Task::spawn::closure.5741
13:     0x7f82bd9d2530 - thread::thread_start::ha943fdda31374bc3i6b
14:     0x7f82bd28a0c0 - start_thread
15:     0x7f82bcb98f89 - __clone
16:                0x0 - <unknown>

It looks like it panics at the moment several lines go out of screen visibility due to new lines)

E.g.

/---------------------------\
| text                      |
| more text                 |
| even more text            |
\---------------------------/

Then I inset more new lines and it crashes at the moment it should look like this

/---------------------------\
| text                      |
| NL                        |
| more text                 |
\---------------------------/
gchp commented 9 years ago

Hmm, this is strange. I'm not seeing the issue, so I can't say too much as to what is causing this for you. There is logic in uibuf.rs which should prevent lines being drawn outside the bounds of the UIBuffer. It could definitely be buggy though.

Are you able to reproduce this consistently?

leonardinius commented 9 years ago

I only did it only like ten times at this point with multiple builds (cargo clean && cargo build)

gchp commented 9 years ago

Hmm ok. What width is your terminal when you are opening the file?

leonardinius commented 9 years ago
$: tput lines
43

$: tput cols
168
gchp commented 9 years ago

Ok, I believe I may have fixed this.

The problem was due to how each line was being drawn. The mechanism for calculating where on the terminal to draw the line (vertically) was not taking into account the possible offset from scrolling long files.

I'll leave the ticket open, to see if you are still having problems. Let me know how it goes!

leonardinius commented 9 years ago

It seems to be fixed now.

Thanks for such a quick turnaround.

Closing the issue.