Closed dpendolino closed 3 years ago
Cleaned up the stacktrace. I'm helping! :)
thread 'main' panicked at 'could not parse layout default', /home/dpendolino/.cargo/registry/src/github.com-1ecc6299db9ec823/zellij-0.5.0/src/client/layout.rs:193:33
stack backtrace:
0: 0x560b4579ab50 - std::backtrace_rs::backtrace::libunwind::trace::h5e9d00f0cdf4f57e
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
1: 0x560b4579ab50 - std::backtrace_rs::backtrace::trace_unsynchronized::hd5302bd66215dab9
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x560b4579ab50 - std::sys_common::backtrace::_print_fmt::ha0237cd11a34e2bf
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys_common/backtrace.rs:67:5
3: 0x560b4579ab50 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h171d4c10df1a98ee
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys_common/backtrace.rs:46:22
4: 0x560b4557897c - core::fmt::write::h89e4288724daa3fa
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/fmt/mod.rs:1096:17
5: 0x560b4579a441 - std::io::Write::write_fmt::h6d40f996e84584d9
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/io/mod.rs:1568:15
6: 0x560b45799df5 - std::sys_common::backtrace::_print::h0c0b93221682afc8
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys_common/backtrace.rs:49:5
7: 0x560b45799df5 - std::sys_common::backtrace::print::h57a9f95204c2fdd6
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys_common/backtrace.rs:36:9
8: 0x560b45799df5 - std::panicking::default_hook::{{closure}}::h4245258b50e37e69
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:208:50
9: 0x560b457994c4 - std::panicking::default_hook::h7b00dcc1d0944747
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:225:9
10: 0x560b457994c4 - std::panicking::rust_panic_with_hook::h71e6a073d87de1f5
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:591:17
11: 0x560b457b8528 - std::panicking::begin_panic_handler::{{closure}}::hd549436f6bb6dbb8
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:497:13
12: 0x560b457b849c - std::sys_common::backtrace::__rust_end_short_backtrace::h4e5f4b72b04174c3
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys_common/backtrace.rs:141:18
13: 0x560b457b844d - rust_begin_unwind
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:493:5
14: 0x560b457b83a0 - std::panicking::begin_panic_fmt::h818c3c917eaeb432
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:435:5
15: 0x560b459bf5f3 - zellij::client::layout::Layout::new::{{closure}}::hb541c0a99ad1208b
16: 0x560b454f92d6 - zellij::common::start::h8e69c5cdf9e2d749
17: 0x560b45a50b23 - zellij::main::hbed77a392253462a
18: 0x560b45a0feb3 - std::sys_common::backtrace::__rust_begin_short_backtrace::hfba298a78a35d802
19: 0x560b45a4ce65 - main
20: 0x7f36a2ef2b25 - __libc_start_main
21: 0x560b454e570e - _start
22: 0x0 - <unknown>
So we tracked it down with strace
. I had a backup nginx config in my home directory called default
. zellij
was picking that up and crashing.
❯ rm default && zellij 14:21:03
Bye from Zellij!
Any idea why it's loading a random file called default
from $HOME?
Yeah, Zellij seems to load a file called 'default' in the CWD:
ron@detritus ~ $ head /dev/urandom > default
ron@detritus ~ $ zellij
thread 'main' panicked at 'could not read layout default', /home/ron/.cargo/registry/src/github.com-1ecc6299db9ec823/zellij-0.5.0/src/client/layout.rs:191:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Seems like it's trying to be opportunistic to load layouts, but default is an awfully generic name. This is gonna cause super confusing bugs for folks. :)
Agreed!
It would probably be best to stick with XDG standards and only look in $XDG_CONFIG_HOME/zellij
which usually maps to $HOME/.config/zellij
.
Thanks that is a great help! Yeah that is definitely an issue, and I don't think that is intended.
Thank you very much for putting in the effort to debug this! Zellij is looking for the default layout and I agree it shouldn't be. Tagging @TheLostLambda on this one: what do you think?
I too had a file (a directory actually) called default
. It's been sent to directory heaven and zellij
starts normally. But, just to be clear, there are two bugs here:
zellij
looks for $CWD/default
by default.zellij
crashes if it doesn't like what it finds in $CWD/default
.zellij crashes if it doesn't like what it finds in $CWD/default
That is a good point, but I am personally not sure if that is not entirely wrong. If you give a layout file and that layout file has errors shouldn't it crash?
What does need fixing is the error warning, and it should definitley not panic.
Ideally we could have some sort of way to give the user notifications while in zellij, that way the loading could fail more gracefully.
@vgivanovic Thank you for the input!
My two cents: Graceful failing is always preferable to crashing (where crashing means exiting without warning or recourse). Fixing the error warning would do the trick, provided zellij
soldiers on, perhaps (depending on the error) in a degraded state.
Heya! I think this is certainly something to be improved. I think that it would be ideal if Zellij checked the type of a file before loading it – there is no good reason for us to try to parse a folder as YAML.
There should also be some more graceful fallback when parsing fails. A human friendly error is probably in order!
Also, this one is more opinion, but I think that if you're not calling Zellij with --layout
, it should actually prefer the default data directory (something like ~/.local/share/zellij/layouts
) over anything in the current directory. Even if a valid default.yaml
is present in the currently directory, I don't think we should pay it any mind unless you're running zellij -l default.yaml
.
Personally, I think a nice error is most important, followed by preferring ~/.local/share/zellij/layouts
, then checking file-type is more of a nice-to-have.
How do people feel about those changes?
@vgivanovic @TheLostLambda I agree with everything here.
@TheLostLambda
I think we should separate the layout flag into layout and layout-path in the future. Where layout looks at all known plugin directories, and layout-path looks at the specific path.
Anything else just seems like it would lead to unwanted edge cases to me.
I think that's a pretty good idea, I'd be up for doing that!
Awesome!
@TheLostLambda Did you already start with it? Otherwise I would be up to start on it, since you pretty much have a lot of stuff to do already.
@a-kenji I've not started yet, so feel free to go for it!
@a-kenji - I think this is fixed already, right? Can we close this issue?
Yes, it is fixed. I kept it open in order to track the other issue that fell out of it. But it is better to create a separate one for it.
Expected behavior:
Crash:
Details: OS: Arch Linux Kernel: 5.11.15-zen1-2-zen cargo 1.51.0 (43b129a20 2021-03-16) /tmp
zellij 0.5.0