piano-rs: panicked at 'called Result::unwrap() on an Err
I cloned from git, built with cargo --build.
- OS: Debian 10
- Rust version: rustc 1.47.0 (18bf6b4f0 2020-10-07)
I got a short error message each time I ran the program (reproduced 3 times) after pressing keys at random, one at a time. So I ran it using RUST_BACKTRACE=1 and got some extra detail.
thread ‘<unnamed>’ panicked at ‘called Result::unwrap() on an Err value: Custom(“invalid value: integer 4169265872, expected variant index 0 <= i < 5”)’, src/network/receiver.rs:25:69
stack backtrace:
0: rust_begin_unwind
at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
1: core::panicking::panic_fmt
at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/panicking.rs:85
2: core::option::expect_none_failed
at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/option.rs:1221
3: core::result::Result<T,E>::unwrap
at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/core/src/result.rs:973
4: piano_rs::network::receiver::Receiver::poll_event
at ./src/network/receiver.rs:25
5: piano_rs::handle_network_receive_event
at ./src/main.rs:37
6: piano_rs::main::{{closure}}
at ./src/main.rs:135
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (17 by maintainers)
@ritiek @Jammyjamjamman found that some packets from another device on my network were interfering. It turned out to be my Google Home mini. After I blocked its IP on my LAN, he couldn’t reproduce the crash.
Note that I was still crashing before when trying your suggestion of using ‘–receiver-address=127.0.0.1:6347’… so I guess the Google thing was sending packets to quite a variety of ports!
Interesting. What do you see when you print the value of ``src` in https://github.com/ritiek/piano-rs/blob/5509a9e4e2204169c2234ca279089aaac942d314/src/network/receiver.rs#L23
Either way, I’ll add checks to make sure to proceed only if the network data received is valid. That should probably fix this.
Me and Andy used tcpdump to listen to the udp port the piano binds to, while using the piano. We could see the packets that are sent when pressing piano keys. However, interestingly, the rouge packet the piano kept receiving on Andy’s computer was not picked up by tcpdump.
So the piano game is picking up data in the udp buffer, but it’s unclear where it’s coming from. We modified the piano program to spit out the
bufcontents in the receiver, when it causes the bincode decoder to panic. This is the content of the buffer when it causes the piano receiver on Andy’s computer to crash:(N.b. I cannot reproduce this bug on my laptop, running Manjaro, kernel 5.9-11, rustc 1.48.0.)
Alright, I see.
Ok, will do this.