"called Option::unwrap() on a None value" crash after running for a few hours

[ssb22]

I let ytop run for a few hours (without interacting with it), and then it crashed with:

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 /builddir/.cargo/registry/src/github.com-1ecc6299db9ec823/size-0.1.2/src/lib.rs, line 169
thread: main

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 version (ytop -V): ytop 0.6.0
• The output of uname -a: Linux localhost.localdomain 5.6.8-300.fc32.x86_64 Implement widgets #1 SMP Wed Apr 29 19:01:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Include any of the following information if relevant:

• Terminal emulator (e.g. iTerm or gnome terminal): gnome-terminal
• tmux version (tmux -V): tmux 3.0a (but I'm not running it)
• Any relevenat hardware info: n/a

Please copy or attach ~/.local/state/ytop/errors.log if it exists and contains logs: (file is empty)

[mgrady3]

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

• Terminal emulator (e.g. iTerm or gnome terminal): gnome-terminal
• tmux version (tmux -V): tmux 3.0a (but I'm not running it)
• Any relevant hardware info:
  • AMD 3900X (12c/24T CPU)
  • 32GB RAM
  • RX580 GPU
  • Gnome desktop environment using Wayland

Please copy or attach ~/.local/state/ytop/errors.log if it exists and contains logs: (file is empty)

 $ cat ~/.local/state/ytop/errors.log 

[cjbassi]

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.

[AlexanderDavid]

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.

[boreq]

$ 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

[CosmicHorrorDev]

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:

• Cloning the repo
• Adding this snippet to the bottom of Cargo.toml

[profile.release]
debug = true

• And running RUST_BACKTRACE=1 cargo run --release from within the project directory to try and get a backtrace that includes debug info

This 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!

[boreq]

   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

[CosmicHorrorDev]

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?

[CosmicHorrorDev]

Now that I look into this more, this actually might not be the cause of the issue. I'm gonna poke around more.

[CosmicHorrorDev]

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.

[CosmicHorrorDev]

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?

[boreq]

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

[CosmicHorrorDev]

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.

[Morgan-iv]

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

[iddm]

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

[CosmicHorrorDev]

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

[mgrady3]

@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.

[CosmicHorrorDev]

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

[mgrady3]

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.