unwraps in network code

[sashahilton00]

Issue by crepererum
Saturday Nov 12, 2016 at 17:32 GMT
Originally opened as plietar/librespot#127

---

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.

[sashahilton00]

Comment by crepererum
Saturday Nov 12, 2016 at 17:33 GMT

---

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

[sashahilton00]

Comment by plietar
Saturday Nov 12, 2016 at 17:53 GMT

---

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 😄

[sashahilton00]

Comment by plietar
Saturday Nov 19, 2016 at 21:49 GMT

---

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

[sashahilton00]

Comment by joerg-krause
Tuesday Jan 10, 2017 at 19:22 GMT

---

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

[sashahilton00]

Comment by crepererum
Friday Jan 13, 2017 at 06:47 GMT

---

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.

[ComlOnline]

Please see #103 for more on this issue.