lorri crash report

[neeasade]

Describe the bug

Crash when running lorri daemon with the install from the current nix-definition on nixpkgs master https://github.com/NixOS/nixpkgs/blob/fe414f371fec215e8a2f0a674883bd68e6d5d371/pkgs/tools/misc/lorri/default.nix

edit: I have not enabled the lorri service in my nixos config/wanted to try on my own first

To Reproduce
Steps to reproduce the behavior:

Run lorri daemon on nixos 19.09

Expected behavior
n/a

Metadata

$ cat /tmp/report-0101c9e0-1369-4179-a946-eb677c8309e2.toml
name = 'lorri'
operating_system = 'unix:Unknown'
crate_version = '0.1.0'
explanation = '''
Panic occurred in file '/build/lorri-unstable-2020-01-09-vendor/slog/src/lib.rs' at line 1914
'''
cause = 'Error cause could not be determined by the application.'
method = 'Panic'
backtrace = '''

   0: 0x5589d5b0b450 - std::panicking::try::do_call::h0bccca25b9fd2488
   1: 0x5589d5d2d4ca - __rust_maybe_catch_panic
   2: 0x5589d5b0c327 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h8af922e9ed3947cc
   3: 0x5589d5d15d1f - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h6c0738f801cabf25
   4: 0x5589d5d17d70 - std::sys_common::thread::start_thread::h315e202f3d241f4f
   5: 0x5589d5d14976 - std::sys::unix::thread::Thread::new::thread_start::h1a956e7fc4c1818a
   6: 0x7f1f8dc55ef7 - start_thread
   7: 0x7f1f8d9751ff - __GI___clone
   8:        0x0 - <unknown>'''

$ lorri info
Well, this is embarrassing.

lorri had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/tmp/report-4776f5fc-f4d7-4ea2-a72d-aa8bad57fbce.toml". Submit an issue or email with the subject of "lorri Crash Report" and include the report as an attachment.

- Homepage: https://github.com/target/lorri
- Authors: Graham Christensen <graham.christensen@target.com>

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

$ uname -a
Linux bridge 4.19.97 #1-NixOS SMP Fri Jan 17 18:47:17 UTC 2020 x86_64 GNU/Linux

Additional context

[Profpatsch]

cause = 'Error cause could not be determined by the application.'

Didn’t we merge an update to human-panic @curiousleo?

explanation = '''
Panic occurred in file '/build/lorri-unstable-2020-01-09-vendor/slog/src/lib.rs' at line 1914
'''

Hm, now I wonder if that’s a slog bug

[neeasade]

This turned out to be a slog bug with emacs shell (it works fine in (x)st) -- still trying to narrow it down

$ RUST_LOG=lorri=debug RUST_BACKTRACE=1 lorri info
thread '<unnamed>' panicked at 'slog::Fuse Drain: Custom { kind: Other, error: "term error: operation not supported by the terminal" }', /build/lorri-unstable-2020-01-09-vendor/slog/src/lib.rs:1914:33
stack backtrace:
   0: std::sys_common::backtrace::print
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::continue_panic_fmt
   5: std::panicking::begin_panic_fmt
   6: <slog::Fuse<D> as slog::Drain>::log::{{closure}}
   7: <slog::Fuse<D> as slog::Drain>::log
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

$ RUST_LOG=lorri=debug RUST_BACKTRACE=full lorri info
thread '<unnamed>' panicked at 'slog::Fuse Drain: Custom { kind: Other, error: "term error: operation not supported by the terminal" }', /build/lorri-unstable-2020-01-09-vendor/slog/src/lib.rs:1914:33
stack backtrace:
   0:     0x55f5ffde4d21 - std::sys_common::backtrace::print::h9deaddc907acff3e
   1:     0x55f5ffdce724 - std::panicking::default_hook::{{closure}}::h8b714f014f696a51
   2:     0x55f5ffdce4b3 - std::panicking::default_hook::h7a76a2461fbf555a
   3:     0x55f5ffdcee20 - std::panicking::rust_panic_with_hook::hb8c1e17e7c78fa8a
   4:     0x55f5ffdce9b2 - std::panicking::continue_panic_fmt::h7ca51f480ac1cd64
   5:     0x55f5ffdce8ff - std::panicking::begin_panic_fmt::hfeb9b2aee2603dd8
   6:     0x55f5ffbd375e - <slog::Fuse<D> as slog::Drain>::log::{{closure}}::h915b9b102b7060af
   7:     0x55f5ffbd3634 - <slog::Fuse<D> as slog::Drain>::log::h87b634dab006edd5
   8:     0x55f5ffc14569 - std::sys_common::backtrace::__rust_begin_short_backtrace::hcc66c361ca5c238e
   9:     0x55f5ffc05bc0 - std::panicking::try::do_call::h989927a1fe4b3bfe
  10:     0x55f5ffde933a - __rust_maybe_catch_panic
  11:     0x55f5ffc18ee7 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h3384739bdd628bac
  12:     0x55f5ffdc9ebf - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::h3e052558cbe55fd8
  13:     0x55f5ffdcf7b0 - std::sys::unix::thread::Thread::new::thread_start::h5262a6ff4b26522f
  14:     0x7fa15e15eef7 - start_thread
  15:     0x7fa15de7e22f - __GI___clone
  16:                0x0 - <unknown>

not a lorri bug, this can be closed.. just want to find the source still (I'm not very rust ecosystem savvy)

[Profpatsch]

I’ll leave it to @curiousleo

[neeasade]

Somewhere in the pipeline there's a term capability check that's not happening I guess? emacs has TERM=dumb for it's shell-mode.

note to self: been looking around at:
https://github.com/target/lorri/blob/8c6536717f8ac5c304d8f22cefffea746cff8343/src/logging.rs
https://github.com/slog-rs/term/search?q=TERM&unscoped_q=TERM
https://github.com/Stebalien/term
rust-lang/rustfmt#1180
Stebalien/term#73

tl;dr -- it appears the slog-term drain uses the term library to get it's capabilities, but for some reason is not being 'dumb' enough in this case

[curiousleo]

@Profpatsch wrote:

Didn’t we merge an update to human-panic @curiousleo?

We did, but haven't released since: https://github.com/target/lorri/compare/unstable-2020-01-09..master#diff-80398c5faae3c069e4e6aa2ed11b28c0

[curiousleo]

@neeasade wrote:

Somewhere in the pipeline there's a term capability check that's not happening I guess? emacs has TERM=dumb for it's shell-mode.

note to self: been looking around at:
https://github.com/target/lorri/blob/8c6536717f8ac5c304d8f22cefffea746cff8343/src/logging.rs
https://github.com/slog-rs/term/search?q=TERM&unscoped_q=TERM
https://github.com/Stebalien/term
rust-lang/rustfmt#1180
Stebalien/term#73

tl;dr -- it appears the slog-term drain uses the term library to get it's capabilities, but for some reason is not being 'dumb' enough in this case

Nice digging! It looks to me too like this is a bug in slog or term. However, there are remedies we could take in lorri if this is a dealbreaker for you. Can you give me an idea of how much of an issue this is as you're trying to use lorri?

[neeasade]

@curiousleo

tl;dr this issue can be closed/I'll poke at upstream another time probably

Thank you -- well, I've been using emacs shell as my term for ~2 years because it is a very nice repl experience (things break down when curses or cursor movement is involved because the shell is treated as an inferior process/doesn't get the display -- that is, the esc codes to do those things are simply ignored). You get all your editor goodies in your shell experience, which is a very nice flow.

if this is a dealbreaker for you.

Not a dealbreaker, I think this is just the universe telling me to try out [1] finally. I'll still use lorri, but would love if this could be resolved on slog/terms end -- that might be digging for another weekend though.

[1] https://github.com/akermu/emacs-libvterm