librespot icon indicating copy to clipboard operation
librespot copied to clipboard

unwraps in network code

Open crepererum opened this issue 7 years ago • 5 comments

The network-related code (e.g. in session.rs) uses unwrap, even in places where failure is kinda likely. For example:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IoError(Error { repr: Os { code: 104, message: "Connection reset by peer" } })', /buil
dslave/rust-buildbot/slave/stable-dist-rustc-cross-host-linux/build/src/libcore/result.rs:799
stack backtrace:
   1:       0x557f3db8d3 - std::sys::backtrace::tracing::imp::write::hd28a1f8221c946e5
   2:       0x557f3dfd9b - std::panicking::default_hook::{{closure}}::hcb904beb56706ec8
   3:       0x557f3de75b - std::panicking::default_hook::hd59cb475a55dc643
   4:       0x557f3dedcf - std::panicking::rust_panic_with_hook::hea2bde53d708eb9a
   5:       ne557f3dec9b - std::panicking::begin_panic::hc4949303f890336e
   6:       0x557f3debeb - std::panicking::begin_panic_fmt::he756d57ad1c1864c
   7:       0x557f3deb8b - rust_begin_unwind
   8:       0x557f40825b - core::panicking::panic_fmt::ha615cb8b8c64841b
   9:       0x557f1a9123 - core::result::unwrap_failed::hf088160fd5523cfd
  10:       0x557f1f211b - librespot::session::Session::recv::h1029c0727cfdd2f5
  11:       0x557f1f1bb7 - librespot::session::Session::poll::h8d6b905a3d50b9e1
  12:       0x557f16f5db - librespot::main::ha3ae70879a6a6aa7
  13:       0x557f3e512f - __rust_maybe_catch_panic
  14:       0x557f3ddedb - std::rt::lang_start::hcb77440d8735d978
  15:       0x7fa1c4a363 - __libc_start_main
  2::       0x557f167363 - <unknown>

Connection resets are a normal thing, esp. in Wifi-environments. So the recv method should probably return a Result-type instead and the layer above (poll) should handle failed connection attempts, e.g. by reconnect/retry.

crepererum avatar Nov 12 '16 17:11 crepererum

Apart from it, I can happily report that librespot runs perfectly on a ODROID-C2, which is an AArch64 platform :smiley:

crepererum avatar Nov 12 '16 17:11 crepererum

Yeah, I wrote librespot while I was still reverse engineering the protocol, so these issues weren't really my priority.

There's a lot of things I'm not too happy with in the code, including this, but I don't really have much time to work on it. One day though ...

Glad to hear it still works :smile:

plietar avatar Nov 12 '16 17:11 plietar

FYI, I'm working on a (partial) rewrite which should be much better at handling network issues

plietar avatar Nov 19 '16 21:11 plietar

I am getting the "Connection reset by peer", too. Any idea why the connection is reset? How can the panic be handled properly?

joerg-krause avatar Jan 10 '17 19:01 joerg-krause

I guess the reset means that either the Spotify server directly or some node in between cuts the TCP connection. This ain't uncommon, expecially when the server suffers under high loads. Network problems are (IMHO) such normal that they shouldn't produce a panic. But as @plietar already mentioned, proof of concept code does hit always follow this rule.

crepererum avatar Jan 13 '17 06:01 crepererum