target/lorri

lorri crashes on `lorri watch` from emacs shell.

Closed this issue · 3 comments

Describe the bug

lorri crashes on lorri watch from emacs shell. Crash log seems to indicate it's due to incorrect terminal capability handing.

To Reproduce
Steps to reproduce the behavior:

  1. Open a (bash) shell in emacs
  2. Navigate to a directory with a shell.nix and a .envrc
  3. Run lorri watch

Metadata

$ lorri info --shell-file shell.nix 
lorri version: 1.0
gc roots exist, shell_gc_root: "/home/mwillsey/.cache/lorri/gc_roots/b248d494210f65e15ff407b42e045d41/gc_root/shell_gc_root"
$ uname -a
Linux nixos 5.4.24 #1-NixOS SMP Thu Mar 5 15:43:52 UTC 2020 x86_64 GNU/Linux

Crash report

name = 'lorri'
operating_system = 'unix:Unknown'
crate_version = '1.0.0'
explanation = '''
Panic occurred in file '/build/lorri-1.0-vendor.tar.gz/slog/src/lib.rs' at line 1914
'''
cause = 'slog::Fuse Drain: Custom { kind: Other, error: "term error: operation not supported by the terminal" }'
method = 'Panic'
backtrace = '''

   0: 0x5573292e4aa0 - std::panicking::try::do_call::h16e5a52efd511179
   1: 0x55732951b3fa - __rust_maybe_catch_panic
   2: 0x55732934e697 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h53598dca4ddea8c8
   3: 0x55732950f1ef - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::he9dcb7073be13c65
   4: 0x5573294fce30 - std::sys_common::thread::start_thread::h9ce8f903e84fe8e9
   5: 0x55732950e866 - std::sys::unix::thread::Thread::new::thread_start::h5e894f0575174d9e
   6: 0x7f8abbcd5edd - start_thread
   7: 0x7f8abbbeca4f - __clone
   8:        0x0 - <unknown>'''

I can repro. I believe this is the same as slog-rs/slog#160, which should be fixed in slog-rs/term@93587a3. However, with slog_term 2.5.0, which contains the fix, I can still repro the issue.

Updating the library is probably not a bad idea anyway, so I'll go ahead and do that. I don't expect it to fix the issue for you though.

@curiousleo we seem to be having lots of trouble with the slog library while only using a small subset of its capabilities.

I wonder whether it won’t be easier in the long-term to replace it by simple printing code (especially since we don’t have any requirements for high-speed output). Or even just json objects, one per line (then people can also filter messages).