rabite0 / hunter

The fastest file manager in the galaxy!
Do What The F*ck You Want To Public License
1.31k stars 64 forks source link

Fix crash at startup on macOS #17

Closed rabite0 closed 5 years ago

rabite0 commented 5 years ago

hunter crashes on startup. Need to investigate.

See: #12

rabite0 commented 5 years ago

EDIT: Please test the "mac-fix" branch!!

I modified the metadata-fetching, so that it doesn't use a threadpool. This might fix the crashing on macOS. I can't test this on my machine, so I can just guess what's wrong. But from the screenshot it seemed to be the cause.

If this works I can dig deeper into it, but if this doesn't fix the crash I might have to install macOS in a VM or something.

mre commented 5 years ago

Just tried it and it works on my mac now. 👍

rabite0 commented 5 years ago

Wow that's great! This is a very suboptimal solution right now, since it might start thousand threads if you enter a directory with that many files.. (previews don't do this) This would make loading actually slower since it overloads the HDD, but it actually seemed to be ok when I ran it. With the threadpool this is limited to 8 threads. It shouldn't affect responsiveness too much anyway, if at all, but it might.

It's good to know where the issue is (the threadpool). Sadly , I can't merge this into master as it is, but I'm working on it. Probably going to do something with conditional compilation.

Thanks for testing.

rabite0 commented 5 years ago

BTW, I'm going to maintain and merge all improvements into the mac-fix branch, until I get to write something that can be merged into master, so feel free to use it if it works for you.

cpdean commented 5 years ago

fwiw, i just tried this on a mac and it worked, but i had to modify how the lscolors crate is being used to get past if you don't have that env var set in your terminal

rabite0 commented 5 years ago

Oh, then that was the actual issue, and not really thread-pool itself. Can probably drop the mac-fix branch then. Thank's for the patch!

wezm commented 5 years ago

Did @cpdean lscolors change get merged? I'm seeing a panic on MacOS (10.13.6), master 8a7ee02:

    Finished dev [unoptimized + debuginfo] target(s) in 0.14s
     Running `target/debug/hunter`
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
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: hunter::die_gracefully::{{closure}}
             at src/main.rs:77
   5: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:478
   6: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   7: std::panicking::try::do_call
             at src/libstd/panicking.rs:308
   8: <T as core::any::Any>::type_id
             at src/libcore/panicking.rs:85
   9: <T as core::any::Any>::type_id
             at src/libcore/panicking.rs:49
  10: <core::option::Option<T>>::unwrap
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/macros.rs:10
  11: core::ops::function::FnOnce::call_once
             at src/files.rs:31
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/ops/function.rs:231
  12: <lazy_static::lazy::Lazy<T>>::get::{{closure}}
             at /Users/wmoore/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-0.2.11/src/lazy.rs:24
  13: std::sync::once::Once::call_once::{{closure}}
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libstd/sync/once.rs:220
  14: std::sync::once::Once::call_once::{{closure}}
             at src/libstd/sync/once.rs:387
  15: std::sync::once::Once::call_once
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libstd/sync/once.rs:220
  16: <hunter::files::COLORS as core::ops::deref::Deref>::deref
             at /Users/wmoore/.cargo/registry/src/github.com-1ecc6299db9ec823/lazy_static-0.2.11/src/lazy.rs:23
             at ./<::lazy_static::__lazy_static_internal macros>:13
             at ./<::lazy_static::__lazy_static_internal macros>:14
  17: hunter::files::File::get_color
             at src/files.rs:776
  18: hunter::files::File::process_meta
             at src/files.rs:748
  19: hunter::files::File::take_meta
             at src/files.rs:741
  20: hunter::files::Files::meta_upto
             at src/files.rs:481
  21: hunter::files::Files::meta_all
             at src/files.rs:454
  22: hunter::file_browser::FileBrowser::new::{{closure}}
             at src/file_browser.rs:267
  23: core::ops::function::FnOnce::call_once
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/libcore/ops/function.rs:231
  24: <F as alloc::boxed::FnBox<A>>::call_box
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/liballoc/boxed.rs:749
  25: <hunter::preview::AsyncWidget<W>>::new::{{closure}}
             at src/preview.rs:285
  26: <F as alloc::boxed::FnBox<A>>::call_box
             at /rustc/bc44841ad2a2ad5f6c5e67b9e35ed8e7e71d4dc7/src/liballoc/boxed.rs:749
  27: <hunter::preview::Async<T>>::run_async
             at src/preview.rs:134
  28: <hunter::preview::Async<T>>::run::{{closure}}
             at src/preview.rs:154
rabite0 commented 5 years ago

Ooops, this got lost somehow. I probably screwed up by pushing my local changes without pulling from the repo first. I'm pretty new to this collaborative development stuff :).

Anyway, it's merged in again.