Open ssb22 opened 4 years ago
Encountered the same problem on Fedora 32 installed from source as described in README.md
.
However, in my scenario, I ran the app for only ~5 minutes.
$ ytop -V
ytop 0.6.0
$ uname -a
Linux localhost.localdomain 5.6.8-300.fc32.x86_64 #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ gnome-shell --version
GNOME Shell 3.36.2
Please copy or attach ~/.local/state/ytop/errors.log if it exists and contains logs: (file is empty)
$ cat ~/.local/state/ytop/errors.log
I'm having a hard time figuring out where the unwrap is occurring, the line number in the error message doesn't seem to be correct for some reason. If we could get a stack trace I think that would really help.
I just got the same crash when I killed a docker build process. I assume that I killed the process at the same time ytop was trying to get information about it.
$ RUST_BACKTRACE=1 ytop --interval 5
Run with RUST_BACKTRACE=full to include source snippets.
Backtrace (most recent call first):
File "<unknown>", line 0, in core::panicking::panic
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in core::fmt::write
File "<unknown>", line 0, in alloc::fmt::format
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in __rust_maybe_catch_panic
File "<unknown>", line 0, in std::rt::lang_start_internal
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in __libc_start_main
File "<unknown>", line 0, in <unknown>
File "<unknown>", line 0, in <unknown>
The application panicked (crashed).
called `Option::unwrap()` on a `None` value
in /cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs, line 169
thread: main
Hello, it's pretty hard to track down this issue without more debug info since there are several places where this issue could be occuring. If someone is able to consistently reproduce this and wouldn't mind:
Cargo.toml
[profile.release]
debug = true
RUST_BACKTRACE=1 cargo run --release
from within the project directory to try and get a backtrace that includes debug infoThis will of course involve having cargo
installed. If no one wants to then I can setup fedora in a VM and see if I can reproduce it locally. I will be on a 3-day hiatus without internet, so I'll get back to this issue when I get back!
Compiling ytop v0.6.2 (/home/filip/ytop)
Finished release [optimized + debuginfo] target(s) in 12m 26s
Running `target/release/ytop`
Run with RUST_BACKTRACE=full to include source snippets.
Backtrace (most recent call first):
File "/build/rust/src/rustc-1.45.0-src/src/libcore/macros/mod.rs", line 10, in core::option::Option<T>::unwrap
File "/home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs", line 169, in size::Size<T>::bytes
File "/home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs", line 192, in size::Size<T>::format
File "/home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs", line 148, in <size::Size<T> as core::fmt::Display>::fmt
File "src/libcore/fmt/mod.rs", line 1076, in core::fmt::write
File "/build/rust/src/rustc-1.45.0-src/src/libcore/fmt/mod.rs", line 193, in core::fmt::Write::write_fmt
File "src/liballoc/fmt.rs", line 586, in alloc::fmt::format
File "src/widgets/net.rs", line 181, in <&ytop::widgets::net::NetWidget as tui::widgets::Widget>::render
File "/home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.9.2/src/terminal.rs", line 65, in tui::terminal::Frame<B>::render_widget
File "src/draw.rs", line 89, in ytop::draw::draw_bottom_row
File "src/draw.rs", line 41, in ytop::draw::draw_widgets
File "src/draw.rs", line 20, in ytop::draw::draw::{{closure}}
File "/home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.9.2/src/terminal.rs", line 187, in tui::terminal::Terminal<B>::draw
File "src/draw.rs", line 8, in ytop::draw::draw
File "src/main.rs", line 177, in ytop::main
The application panicked (crashed).
called `Option::unwrap()` on a `None` value
in /home/filip/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs, line 169
thread: main
Thanks for the debug info! I opened #104 to address this, but just because I'm curious did this crash happen after some time, or was it immediate?
Now that I look into this more, this actually might not be the cause of the issue. I'm gonna poke around more.
If anyone wouldn't mind pulling this branch (you can look at the commits, I just added logging for all entry points into size::Size::Bytes
) and following the same procedures above to run with debug info that would be very helpful. It looks like the problem occurs within size
in a case that doesn't really make sense to me so getting a reproducible value would be tremendously helpful. AFAIK this has only been happening on Fedora too which makes it even more peculiar.
After a crash there should actually be a ~/.local/state/ytop/errors.log
file and only the very end of it should be relevant since that would be the last value for the crash. I'm currently running an extensive test against all u64
inputs to size::Size::Bytes
to see if that turns up anything, but that's not on Fedora so it may be a waste of time. I'll be away from the internet for a few days so I'll revisit this when I get back.
My best hunch would be that this is specific to a rustc
version since the program should be compiled respecting the lock-file so all the dependencies should be the same. @boreq can you post the output of rustc -V
?
Thanks for the debug info! I opened #104 to address this, but just because I'm curious did this crash happen after some time, or was it immediate?
Pretty much within 10 minutes of starting it although I am not completely sure as I ran ytop in a tmux session and then switched to another session glancing at ytop from time to time. If we define crashing immediately as for example crashing within 5 seconds of starting the program then it didn't crash immediately.
My best hunch would be that this is specific to a rustc version since the program should be compiled respecting the lock-file so all the dependencies should be the same. @boreq can you post the output of rustc -V?
$ cargo --version
cargo 1.45.0
$ rustc --version
rustc 1.45.0
Hmmm, that's the newest version so that pretty much rules out an outdated compiler.
I don't think #104 will be a fix either since the unwrap seems to be happening inside size::Size::Bytes
and it should be occuring immediately on program start if #104 was the problem.
The last thing I can think of currently is that there is some weird behavior that seems to just be occuring on Fedora with Bytes
, so hopefully someone can find a reproducible case using the branch linked above to help narrow this down. I'll be setting up a Fedora VM and trying to reproduce it locally in a few days if no one finds out more before that.
Same problem, error log:
$ RUST_BACKTRACE=full ytop
Backtrace (most recent call first):
File "<unknown>", line 0, in <size::Size<T> as core::fmt::Display>::fmt
File "rust:src/libcore/fmt/mod.rs", line 1069, in core::fmt::write
File "rust:src/libcore/fmt/mod.rs", line 193, in core::fmt::Write::write_fmt
File "rust:src/liballoc/fmt.rs", line 586, in alloc::fmt::format
File "<unknown>", line 0, in <&ytop::widgets::net::NetWidget as tui::widgets::Widget>::render
File "<unknown>", line 0, in ytop::draw::draw_bottom_row
File "<unknown>", line 0, in ytop::draw::draw_widgets
File "<unknown>", line 0, in tui::terminal::Terminal<B>::draw
File "<unknown>", line 0, in ytop::main
File "<unknown>", line 0, in std::rt::lang_start::{{closure}}
File "rust:src/libstd/rt.rs", line 52, in std::rt::lang_start_internal::{{closure}}
File "rust:src/libstd/panicking.rs", line 331, in std::panicking::try::do_call
File "rust:src/libstd/panicking.rs", line 274, in std::panicking::try
File "rust:src/libstd/panic.rs", line 394, in std::panic::catch_unwind
File "rust:src/libstd/rt.rs", line 51, in std::rt::lang_start_internal
File "<unknown>", line 0, in main
File "<unknown>", line 0, in __libc_start_main
File "<unknown>", line 0, in _start
The application panicked (crashed).
called `Option::unwrap()` on a `None` value
in /home/morgan/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs, line 169
thread: main
Other info:
$ uname -a
Linux morgan-GF63-Thin-9RCX 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ ytop -V
ytop 0.6.2
$ tmux -V
tmux 3.0a
I'm using gnome-terminal as terminal emulator, distro is Linux Mint 20, errors.log is empty. Got this problem many times, usually after 10+ hours and randomly. rustc and cargo are latest, but I'm pretty sure that I installed crate on previous version (1.44.0 or 1.44.1).
I will try to use ytop with debug=true and write here after new crash
This has happened to me just now, after having running it for a minute, not more:
❯ ytop
Backtrace omitted. Run with RUST_BACKTRACE=1 to display it.
Run with RUST_BACKTRACE=full to include source snippets.
The application panicked (crashed).
called `Option::unwrap()` on a `None` value
in /home/fx/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs, line 184
thread: main
Can anyone who is able to get this problem consistently use the branch i listed earlier and post the logs after a crash. I tried livebooting, a VM, and some other random programs and never was able to reproduced
@LovecraftianHorror, I had this problem initially, and later went to try your branch. However, when running from the branch with the instructions posted earlier, ytop
was able to run over night with no failure.
I have not come up with a consistent way to demonstrate the failure as of yet.
Hmmm, that's peculiar. All my branch does is log the values before the points that it would cause a crash. I can try to reproduce again, but wasn't noticing any crashes after several days
right. I am wondering if perhaps in between when I reported the error and when I tested again on your branch if I hadn't made some system updates that could have affected the reported behavior.
I'll do some more testing to see if I can reproduce the crash in my current system state.
I let
ytop
run for a few hours (without interacting with it), and then it crashed with:This is on Fedora 32, installed as described in Fedora Magazine.
I tried running
RUST_BACKTRACE=full ytop
but so far the problem has not recurred. Reporting anyway on the off-chance that it's still useful without the backtrace.Required information:
ytop -V
): ytop 0.6.0uname -a
: Linux localhost.localdomain 5.6.8-300.fc32.x86_64 #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 x86_64 GNU/LinuxInclude any of the following information if relevant:
tmux -V
): tmux 3.0a (but I'm not running it)Please copy or attach
~/.local/state/ytop/errors.log
if it exists and contains logs: (file is empty)