[GH-ISSUE #37] unwraps in network code

kerem commented

2026-02-27 19:28:23 +03:00

Owner

Originally created by @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/37

Issue by crepererum
Saturday Nov 12, 2016 at 17:32 GMT
Originally opened as https://github.com/plietar/librespot/issues/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.

Originally created by @sashahilton00 on GitHub (Jan 29, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/37 <a href="https://github.com/crepererum"><img src="https://avatars1.githubusercontent.com/u/1529400?v=4" align="left" width="96" height="96" hspace="10"></img></a> **Issue by [crepererum](https://github.com/crepererum)** _Saturday Nov 12, 2016 at 17:32 GMT_ _Originally opened as https://github.com/plietar/librespot/issues/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.

kerem

2026-02-27 19:28:23 +03:00

closed this issue
added the
imported
label

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

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 commented on GitHub (Jan 29, 2018): <a href="https://github.com/crepererum"><img src="https://avatars1.githubusercontent.com/u/1529400?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [crepererum](https://github.com/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 :smiley:

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

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 commented on GitHub (Jan 29, 2018): <a href="https://github.com/plietar"><img src="https://avatars0.githubusercontent.com/u/1489775?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [plietar](https://github.com/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 :smile:

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

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 commented on GitHub (Jan 29, 2018): <a href="https://github.com/plietar"><img src="https://avatars0.githubusercontent.com/u/1489775?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [plietar](https://github.com/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

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

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 commented on GitHub (Jan 29, 2018): <a href="https://github.com/joerg-krause"><img src="https://avatars2.githubusercontent.com/u/6870896?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [joerg-krause](https://github.com/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?

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Jan 29, 2018):

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.

@sashahilton00 commented on GitHub (Jan 29, 2018): <a href="https://github.com/crepererum"><img src="https://avatars1.githubusercontent.com/u/1529400?v=4" align="left" width="48" height="48" hspace="10"></img></a> **Comment by [crepererum](https://github.com/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.

kerem commented

2026-02-27 19:28:24 +03:00

Author

Owner

@ComlOnline commented on GitHub (Jan 29, 2018):

Please see #103 for more on this issue.

@ComlOnline commented on GitHub (Jan 29, 2018): Please see #103 for more on this issue.

Rows
Columns

[GH-ISSUE #37] unwraps in network code #25