index out of bounds: the len is 0 but the index is 3
Closed this issue · 7 comments
Hello,
After running ytop for a few hours I get this error below. I've encountered it a few times and I'm unsure how to debug it. Is it possible to run ytop with RUST_BACKTRACE=1 as a flag to find the bug?
Thanks for your work on this app.
Cheers.
Info
ytop 0.6.2
Darwin rrfd.local 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64
Include any of the following information if relevant:
ProductName: Mac OS X
ProductVersion: 10.14.6
BuildVersion: 18G5033
alacritty 0.5.0-dev (65bff18)
tmux 3.1b
Please copy or attach ~/.local/state/ytop/errors.log if it exists and contains logs:
Does not exist
Error Message:
Backtrace omitted. Run with RUST_BACKTRACE=1 to display it.
Run with RUST_BACKTRACE=full to include source snippets.
The application panicked (crashed).
index out of bounds: the len is 0 but the index is 3
in rust:src/libcore/slice/mod.rs, line 2842
thread: main
Hi, well at the very least you're able to get the same error which should make debugging quite a bit easier.
Sadly the error with the panic isn't super helpful because it could really come from anywhere that a slice is taken. you could run ytop and try to get a backtrace the next time the error occurs with RUST_BACKTRACE=full ytop, but that likely won't give any useful information since the ytop you have likely has debugging information stripped already.
If it's not too much of a hassle you could clone the repo and change the commit to the release that you're currently using (f245bab) and then build it with debug symbols and run that to try and get the error again. If you do this then there will be the full backtrace showing where the error occurred which would be very useful (This would involve having cargo installed so that you can build the project locally). The general idea would be
git clone git@github.com:cjbassi/ytop.git
cd ytop
git checkout f245babba2e2f4cc8e35605995948c7c0f37d3d5
cargo run # <-- This will compile and run the project with debug information
If you could follow through these steps and can post the backtrace from the crash then I would be more than happy to hunt down the issue. Without the full backtrace though finding the cause will be very difficult, to say the least. I'm hoping to work on improving the logging situation sometime so that we can get more information on where different crashes are occurring without having to jump through all these hoops, and to better track down very hard to reproduce errors. If for whatever reason running the unoptimized version doesn't cause the crash you can also enable debug info for release builds, but I'll wait to see if we can get the problem again using the steps above first!
This is great @LovecraftianHorror
Let me do the above and I'll get back to you.
Thanks for all your hard work.
@LovecraftianHorror I've been running ytop for two days now using the commit you suggested, without the issue appearing. It usually appears after ytop has been running for a few hours.
However, I'm now getting a different rendering issue, where all the metrics ytop shows become jumbled. I'm not getting an error message, so the program seems to be running correctly. Are there log files I can share to diagnose this?
Hmm, those are some weird graphical issues. That should be the same commit as the package you currently have and I feel like i remember running into some weird problems like that myself when I was working on ytop. I would try running a release build to see if you still get graphical problems (cargo run --release). To actually keep debugging data you'll have to add
[profile.release]
debug = 1To the bottom of Cargo.toml. and thanks for being willing to help get debugging information!
Ran ytop again until a crash happened with cargo run --release. Here is what was returned:
Backtrace omitted. Run with RUST_BACKTRACE=1 to display it.
Run with RUST_BACKTRACE=full to include source snippets.
The application panicked (crashed).
index out of bounds: the len is 0 but the index is 5
in src/widgets/proc.rs, line 346
thread: main
%
Well, that is a rather peculiar issue since the only time that should occur is when there are no processes to list so this is likely a (possibly mac specific) bug in the library we use for process information. It's possible that this will involve some fix there as well, but it seems infrequent at the very least if it only normally occurs after several hours.
Anyways I went ahead and submitted a PR (#102) that should fix this issue at least, so we'll see what more turns up after that's merged I suppose. Thanks for sticking around and helping to provide debugging info, I don't think I'd be able to hunt down the cause of this without it!
No worries. I'll close this issue for now, and update my ytop. If it comes up again, I'll post again here. Thanks for all your help!