panicking with AsyncError("Not ready yet!")

[s-d-m]

I can get the program to crash on my machine doing the following:

1/ go to my home folder (either from within hunter, or start hunter from ~) 2/ press 's'

I get the following stack trace.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: AsyncError("Not ready yet!")', src/libcore/result.rs:997:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
   9: alloc::slice::<impl [T]>::sort_by::{{closure}}
  10: alloc::slice::merge_sort
  11: hunter::files::Files::sort
  12: <hunter::listview::ListView<hunter::files::Files> as hunter::listview::Listable>::on_key
  13: <hunter::file_browser::FileBrowser as hunter::widget::Widget>::on_key
  14: hunter::widget::Widget::handle_input
  15: hunter::main
  16: std::rt::lang_start::{{closure}}
  17: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:297
  18: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:92
  19: std::rt::lang_start_internal
             at src/libstd/panicking.rs:276
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  20: main
  21: __libc_start_main
  22: _start

sorting by size in other folders works for me though

[s-d-m]

Sorry, I forgot to say: I'm running debian sid on x86_64.

[rabite0]

Weird. Does this really happen with just by name sorting?

That shouldn't even interact with the metadata stuff. Is there a file you don't have permissions for to read them? Or some link or something like that?

Could you try with a debug build (run "cargo run" in the source directory) to get line numbers in the backtrace?

There are a few unwraps in the sort method that I probably should get rid of, but they only happen when sorting by size/mdate, which is why this confuses me a little.

[rabite0]

I pushed a new branch "sort-crash-fix" where I removed the unwraps. it also prints the current file names that are being sorted on stderr.

Could you try running it with "cargo run 2> dbg.txt"? It would really help to see which file causes the crashing, if it crashes at all with the changes.

[s-d-m]

Hi rabite0.

Good news: the crash is fixed in your branch sort-crash-fix. Congratulations! Bad news, I got a different crash now:

thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/slice/mod.rs:2539:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic_bounds_check
             at src/libcore/panicking.rs:61
   9: <usize as core::slice::SliceIndex<[T]>>::index
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/slice/mod.rs:2539
  10: core::slice::<impl core::ops::index::Index<I> for [T]>::index
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/slice/mod.rs:2396
  11: <alloc::vec::Vec<T> as core::ops::index::Index<I>>::index
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/liballoc/vec.rs:1677
  12: <hunter::listview::ListView<hunter::files::Files>>::selected_file
             at src/listview.rs:183
  13: hunter::file_browser::FileBrowser::selected_file
             at src/file_browser.rs:716
  14: hunter::file_browser::FileBrowser::cache_files
             at src/file_browser.rs:666
  15: <hunter::file_browser::FileBrowser as hunter::widget::Widget>::refresh
             at src/file_browser.rs:1030
  16: <hunter::tabview::TabView<T> as hunter::widget::Widget>::refresh
             at src/tabview.rs:164
  17: hunter::widget::Widget::handle_input
             at src/widget.rs:403
  18: hunter::run
             at src/main.rs:91
  19: hunter::main
             at src/main.rs:70
  20: std::rt::lang_start::{{closure}}
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libstd/rt.rs:64
  21: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  22: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  23: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  24: std::rt::lang_start
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libstd/rt.rs:64
  25: main
  26: __libc_start_main
  27: _start

This one is easy to reproduce.

1. create a folder
2. put some files in it (just one file is enough)
3. start hunter and go to that folder
4. on a different terminal, remove files in that folder (removing all of them is enough)
5. wait for hunter to crash

This is reproducible both with the master branch and the sort-crash-fix one. It seems hunter does not update the number of files contained in a folder as the number on the right of a folder name doesn't increase or decrease with adding or removing files in that folder. Could be the issue here I think.

Anyway, this is a new issue hence feel free to close this one and open a new one.

[s-d-m]

Another similar crash:

1. Ctrl+F (filter)
2. enter a pattern that do not match any file in the folder

crash with Thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0'

[rabite0]

Ugh... Yeah, it probably gets the index from the whole directory vector somewhere, instead of using the getter method which filters the files. Will look into that.

The filter crash is probably easy to fix, will do that tomorrow.

[rabite0]

Thanks for testing btw.

[rabite0]

Ah, got the wrong, but yeah, still basically the same solution for both of those bugs. Merged in the fix.

Still it's a bit unsettling since that means there is something wrong elsewhere and it can't get the metadata for some particular file/directory/link/whatever. Oh well, closing this.

[s-d-m]

Thanks for looking into this and for your reactivity.

Don't let these bugs demoralize you! Your project is awesome and replaced ranger already for me on quite a few occasions.

[rabite0]

Not at all, I'm happy that people use it and care enough to report bugs and try out possible fixes.

In fact as I see it the response is overwhelmingly positive, almost 250 stars in what, two days? That's way more than I expected. Not to mention people helping with fleshing out the readme and such. Amazing! Oh yeah, and people making PKGBUILDs as soon as it was up, too.

I'm going on vacation with regard to new features for now, since the last few months working full-time on this got a little exhausting towards the end and I need to recharge, but I still want to fix issues as soon as possible, so don't hold back, especially if it's a crash. That kills the user (experience).