[GH-ISSUE #289] Crash upon connect

kerem commented

2026-02-27 19:29:20 +03:00

Owner

Originally created by @patrickjane on GitHub (Feb 20, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/289

I have just compiled librespot on my raspberry pi 3 (raspbian stretch), and librespot crashed after some of my connect attempts. The first 2 attempts succeeded and I was able to play music, however then when starting librespot and connecting on my iPhone librespot crashed:

pi@pi3HA ~/librespot/target/release $ ./librespot -b 320 -n PiTify --initial-volume 50
INFO:librespot: librespot d2cadec (2018-11-19). Built on 2019-02-20. Build ID: 10aRpwDZ
WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `[103, 240, 106, 189, 52, 76, 106, 22, 74, 173, 54, 38, 0, 179, 204, 242, 181, 163, 112, 231]`,
 right: `[48, 194, 35, 67, 138, 4, 128, 136, 73, 67, 19, 105, 247, 6, 138, 164, 69, 223, 98, 161]`', connect/src/discovery.rs:135:9
stack backtrace:
   0:   0x88bb07 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h508e385542e74f0f
                       at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:   0x886177 - std::sys_common::backtrace::_print::h0654a4145b8e108e
                       at src/libstd/sys_common/backtrace.rs:71
   2:   0x88a41b - std::panicking::default_hook::{{closure}}::h9d3b4aa9777cceab
                       at src/libstd/sys_common/backtrace.rs:59
                       at src/libstd/panicking.rs:211
   3:   0x88a08f - std::panicking::default_hook::h54bc90cfc6073aee
                       at src/libstd/panicking.rs:227
   4:   0x88ab8b - std::panicking::rust_panic_with_hook::h28b9ce6fa7a5033b
                       at src/libstd/panicking.rs:491
   5:   0x88a70b - std::panicking::continue_panic_fmt::h4c221b9431554bc2
                       at src/libstd/panicking.rs:398
   6:   0x88a65b - std::panicking::begin_panic_fmt::hf946e5e7aa3496df
                       at src/libstd/panicking.rs:353
   7:   0x49ae37 - librespot_connect::discovery::Discovery::handle_add_user::he48a8e42a114f751
   8:   0x4af28f - <futures::future::chain::Chain<A, B, C>>::poll::hf331e7955b32fd55
   9:   0x49c6f3 - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::hd9fb84c09a20922b
  10:   0x4c13f7 - <hyper::proto::h1::dispatch::Dispatcher<D, Bs, I, B, T>>::poll_until_shutdown::heaac2c7c0bfe566d
  11:   0x4adf03 - <futures::future::chain::Chain<A, B, C>>::poll::h281837b93b57cf3d
  12:   0x7c822f - <futures::task_impl::Spawn<T>>::poll_future_notify::h931efe2e830da2ac
  13:   0x7c1dff - <std::thread::local::LocalKey<T>>::with::hc3a8029fee014330
  14:   0x7bfb1f - <tokio::executor::current_thread::scheduler::Scheduler<U>>::tick::h27dd7c014f4b2fb6
  15:   0x7c0007 - <scoped_tls::ScopedKey<T>>::set::h1efe6dac9ad57e4c
  16:   0x7c17b3 - <std::thread::local::LocalKey<T>>::with::h6273915814956e31
  17:   0x7c1cef - <std::thread::local::LocalKey<T>>::with::h922debe52c28333b
  18:   0x7c13db - <std::thread::local::LocalKey<T>>::with::h3769576f7dc53a87
  19:   0x7bc013 - tokio_core::reactor::Core::poll::hab524b91b82b371f
  20:   0x4690e7 - tokio_core::reactor::Core::run::h2f50c46053f520bd
  21:   0x47741f - librespot::main::he80615b7b40fb7e1
  22:   0x46e26b - std::rt::lang_start::{{closure}}::h7d8586f9b4276de3
  23:   0x88a56f - std::panicking::try::do_call::hf93a787b72e1d226
                       at src/libstd/rt.rs:59
                       at src/libstd/panicking.rs:310
  24:   0x8972cf - __rust_maybe_catch_panic
                       at src/libpanic_unwind/lib.rs:102
  25:   0x88aeff - std::rt::lang_start_internal::h7b3bd8c78881c37d
                       at src/libstd/panicking.rs:289
                       at src/libstd/panic.rs:398
                       at src/libstd/rt.rs:58
  26:   0x4780a3 - main
  27: 0x76d71677 - __libc_start_main

Also, even when playback succeeded, I saw a lot of those warnings:

WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }
WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" }

Originally created by @patrickjane on GitHub (Feb 20, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/289 I have just compiled librespot on my raspberry pi 3 (raspbian stretch), and librespot crashed after some of my connect attempts. The first 2 attempts succeeded and I was able to play music, however then when starting librespot and connecting on my iPhone librespot crashed: ``` pi@pi3HA ~/librespot/target/release $ ./librespot -b 320 -n PiTify --initial-volume 50 INFO:librespot: librespot d2cadec (2018-11-19). Built on 2019-02-20. Build ID: 10aRpwDZ WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" } thread 'main' panicked at 'assertion failed: `(left == right)` left: `[103, 240, 106, 189, 52, 76, 106, 22, 74, 173, 54, 38, 0, 179, 204, 242, 181, 163, 112, 231]`, right: `[48, 194, 35, 67, 138, 4, 128, 136, 73, 67, 19, 105, 247, 6, 138, 164, 69, 223, 98, 161]`', connect/src/discovery.rs:135:9 stack backtrace: 0: 0x88bb07 - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h508e385542e74f0f at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: 0x886177 - std::sys_common::backtrace::_print::h0654a4145b8e108e at src/libstd/sys_common/backtrace.rs:71 2: 0x88a41b - std::panicking::default_hook::{{closure}}::h9d3b4aa9777cceab at src/libstd/sys_common/backtrace.rs:59 at src/libstd/panicking.rs:211 3: 0x88a08f - std::panicking::default_hook::h54bc90cfc6073aee at src/libstd/panicking.rs:227 4: 0x88ab8b - std::panicking::rust_panic_with_hook::h28b9ce6fa7a5033b at src/libstd/panicking.rs:491 5: 0x88a70b - std::panicking::continue_panic_fmt::h4c221b9431554bc2 at src/libstd/panicking.rs:398 6: 0x88a65b - std::panicking::begin_panic_fmt::hf946e5e7aa3496df at src/libstd/panicking.rs:353 7: 0x49ae37 - librespot_connect::discovery::Discovery::handle_add_user::he48a8e42a114f751 8: 0x4af28f - <futures::future::chain::Chain<A, B, C>>::poll::hf331e7955b32fd55 9: 0x49c6f3 - <futures::future::and_then::AndThen<A, B, F> as futures::future::Future>::poll::hd9fb84c09a20922b 10: 0x4c13f7 - <hyper::proto::h1::dispatch::Dispatcher<D, Bs, I, B, T>>::poll_until_shutdown::heaac2c7c0bfe566d 11: 0x4adf03 - <futures::future::chain::Chain<A, B, C>>::poll::h281837b93b57cf3d 12: 0x7c822f - <futures::task_impl::Spawn<T>>::poll_future_notify::h931efe2e830da2ac 13: 0x7c1dff - <std::thread::local::LocalKey<T>>::with::hc3a8029fee014330 14: 0x7bfb1f - <tokio::executor::current_thread::scheduler::Scheduler<U>>::tick::h27dd7c014f4b2fb6 15: 0x7c0007 - <scoped_tls::ScopedKey<T>>::set::h1efe6dac9ad57e4c 16: 0x7c17b3 - <std::thread::local::LocalKey<T>>::with::h6273915814956e31 17: 0x7c1cef - <std::thread::local::LocalKey<T>>::with::h922debe52c28333b 18: 0x7c13db - <std::thread::local::LocalKey<T>>::with::h3769576f7dc53a87 19: 0x7bc013 - tokio_core::reactor::Core::poll::hab524b91b82b371f 20: 0x4690e7 - tokio_core::reactor::Core::run::h2f50c46053f520bd 21: 0x47741f - librespot::main::he80615b7b40fb7e1 22: 0x46e26b - std::rt::lang_start::{{closure}}::h7d8586f9b4276de3 23: 0x88a56f - std::panicking::try::do_call::hf93a787b72e1d226 at src/libstd/rt.rs:59 at src/libstd/panicking.rs:310 24: 0x8972cf - __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:102 25: 0x88aeff - std::rt::lang_start_internal::h7b3bd8c78881c37d at src/libstd/panicking.rs:289 at src/libstd/panic.rs:398 at src/libstd/rt.rs:58 26: 0x4780a3 - main 27: 0x76d71677 - __libc_start_main ``` Also, even when playback succeeded, I saw a lot of those warnings: ``` WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" } WARN:mdns::fsm: error sending packet Os { code: 99, kind: AddrNotAvailable, message: "Cannot assign requested address" } ```

kerem closed this issue

2026-02-27 19:29:20 +03:00

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 11, 2019):

this is likely a bad implementation of zeroconf/multicast on your router, potentially dropped/bad packets.

@sashahilton00 commented on GitHub (Mar 11, 2019): this is likely a bad implementation of zeroconf/multicast on your router, potentially dropped/bad packets.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 11, 2019):

You mean a firewall issue? I am using pfsense, how would I make it not "drop bad packets"?

@patrickjane commented on GitHub (Mar 11, 2019): You mean a firewall issue? I am using pfsense, how would I make it not "drop bad packets"?

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 11, 2019):

it might be a firewall issue, but I would guess it's more likely an underlying issue with the actual multicast implementation on your router. We've seen it happen once or twice before https://github.com/librespot-org/librespot/issues/278#issuecomment-444884325, though it's hard to say for certain as all one can see in the crash logs is that the assertion in the authentication handler failed. You could try disabling the firewall whilst testing and seeing if that helps, and if so, gradually turning parts back on to identify problematic area, but other than that, we're going to struggle ot be of much use here.

@sashahilton00 commented on GitHub (Mar 11, 2019): it might be a firewall issue, but I would guess it's more likely an underlying issue with the actual multicast implementation on your router. We've seen it happen once or twice before https://github.com/librespot-org/librespot/issues/278#issuecomment-444884325, though it's hard to say for certain as all one can see in the crash logs is that the assertion in the authentication handler failed. You could try disabling the firewall whilst testing and seeing if that helps, and if so, gradually turning parts back on to identify problematic area, but other than that, we're going to struggle ot be of much use here.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 12, 2019):

What kind of issue would the multicast have? Could you provide some more details about the issue, so I could ask on pfsense Support Forums?
Would debugging the issue help?

@patrickjane commented on GitHub (Mar 12, 2019): What kind of issue would the multicast have? Could you provide some more details about the issue, so I could ask on pfsense Support Forums? Would debugging the issue help?

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 12, 2019):

I can't say for sure, I know very little about how multicast works, I just know from previous issues here that some implementations are bad/not compliant, which can lead to librespot erroring on some networks. I suggest trying to log in to librespot manually, and if that works consistently, then you can say with a degree of certainty that an issue with multicast is likely the issue. If it fails with manual login, then that woul suggest a problem with the firewall or librespot.

@sashahilton00 commented on GitHub (Mar 12, 2019): I can't say for sure, I know very little about how multicast works, I just know from previous issues here that some implementations are bad/not compliant, which can lead to librespot erroring on some networks. I suggest trying to log in to librespot manually, and if that works consistently, then you can say with a degree of certainty that an issue with multicast is likely the issue. If it fails with manual login, then that woul suggest a problem with the firewall or librespot.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Okay so without any more infos I doubt I can go over to the pfsense guys and ask them whats wrong. Also, I doubt that there is any issue within the pfsense implementation, since its a really widely used and stable unix distribution.

I've just installed the spotify app on my TV, and using my phone via spotify connect on the TV, and I had none of those issues. Playback is fine, I can connect/reconnect as I want, switch tracks etc pp.
So I doubt again that its some issue with my router.

@patrickjane commented on GitHub (Mar 13, 2019): Okay so without any more infos I doubt I can go over to the pfsense guys and ask them whats wrong. Also, I doubt that there is any issue within the pfsense implementation, since its a really widely used and stable unix distribution. I've just installed the spotify app on my TV, and using my phone via spotify connect on the TV, and I had none of those issues. Playback is fine, I can connect/reconnect as I want, switch tracks etc pp. So I doubt again that its some issue with my router.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

And how did you specify the credentials for the Spotify app on your TV? If you specified them manually (the only option with the particular app on my aging TV, for example) then that's not the same as what you've configured librespot to do. Have you tried logging in manually (by explicitly setting your credentials using librespot's --username and --password options?) as @sashahilton00 suggested? That would help narrow things down.

@kingosticks commented on GitHub (Mar 13, 2019): And how did you specify the credentials for the Spotify app on your TV? If you specified them manually (the only option with the particular app on my aging TV, for example) then that's not the same as what you've configured librespot to do. Have you tried logging in manually (by explicitly setting your credentials using librespot's `--username` and `--password` options?) as @sashahilton00 suggested? That would help narrow things down.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

I haven't specified credentials. I started the app on my TV (LG55C8 with webOS 3.5) and just attached my phone. No credentials necessary.

I haven't yet tried with manual credentials in librespot, going to try later.

@patrickjane commented on GitHub (Mar 13, 2019): I haven't specified credentials. I started the app on my TV (LG55C8 with webOS 3.5) and just attached my phone. No credentials necessary. I haven't yet tried with manual credentials in librespot, going to try later.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Okay so indeed, when supplying credentials to librespot, the issue does not happen.

As additional info, since this isn't made very clear in my original post, and I just had to remember myself how to reproduce this:

start librespot
connect device and start playback
stop librespot via CTRL+C
start librespot
connect device <--- in 4 out of 5 tried librespot will crash

I admit that this isn't a normal usecase, but most likely I stumbled across this as I had issues switching songs after connecting and playback started.
I am still having those song-switching issues, should I create a seprate issue for this, or is this a known issue?

@patrickjane commented on GitHub (Mar 13, 2019): Okay so indeed, when supplying credentials to `librespot`, the issue does not happen. As additional info, since this isn't made very clear in my original post, and I just had to remember myself how to reproduce this: 1) start librespot 2) connect device and start playback 3) stop librespot via CTRL+C 4) start librespot 5) connect device <--- in 4 out of 5 tried librespot will crash I admit that this isn't a normal usecase, but most likely I stumbled across this as I had issues switching songs after connecting and playback started. I am still having those song-switching issues, should I create a seprate issue for this, or is this a known issue?

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

If you wait a bit (or restart Spotify on your device) before step 5 do you still get this problem? Perhaps your device is still using the public key from the original librespot instance (1.) rather than the new instance (4.) when it tries to calculate the new MAC?

@kingosticks commented on GitHub (Mar 13, 2019): If you wait a bit (or restart Spotify on your device) before step 5 do you still get this problem? Perhaps your device is still using the public key from the original librespot instance (1.) rather than the new instance (4.) when it tries to calculate the new MAC?

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Okay I can confirm that waiting a bit between the re-connects will not result in a crash.

@patrickjane commented on GitHub (Mar 13, 2019): Okay I can confirm that waiting a bit between the re-connects will not result in a crash.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

Should be pretty simple to add some error messages and better handling (we don't need to panic, just abort the auth attempt) of this situation.

@kingosticks commented on GitHub (Mar 13, 2019): Should be pretty simple to add some error messages and better handling (we don't need to panic, just abort the auth attempt) of this situation.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

Fancy trying out my fix, @patrickjane ?

@kingosticks commented on GitHub (Mar 13, 2019): Fancy trying out my fix, @patrickjane ?

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Sure. Gonna take a while for it to compile on my pi tho.

@patrickjane commented on GitHub (Mar 13, 2019): Sure. Gonna take a while for it to compile on my pi tho.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@ashthespy commented on GitHub (Mar 13, 2019):

Sure. Gonna take a while for it to compile on my pi tho.

Docker to the rescue! ;-)

@ashthespy commented on GitHub (Mar 13, 2019): > > > Sure. Gonna take a while for it to compile on my pi tho. [Docker](https://github.com/librespot-org/librespot/wiki/Cross-compiling) to the rescue! ;-)

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

I hate docker :|

@patrickjane commented on GitHub (Mar 13, 2019): I hate docker :|

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

Just keep in mind that my "fix" here is just not to crash! The client using the wrong key for a period of time (assuming I'm right) is not something librespot can do anything about. That's more of a client bug.

I guess librespot could store and then reuse it's keypair rather than regenerating it, but I'm not really into that idea.

@kingosticks commented on GitHub (Mar 13, 2019): Just keep in mind that my "fix" here is just not to crash! The client using the wrong key for a period of time (assuming I'm right) is not something librespot can do anything about. That's more of a client bug. I guess librespot could store and then reuse it's keypair rather than regenerating it, but I'm not really into that idea.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Its fine, really. Just not making it crash sounds like a good fix. This situation is not a normal usecase anway, in which case error instead of crash sounds viable.

@patrickjane commented on GitHub (Mar 13, 2019): Its fine, really. Just not making it crash sounds like a good fix. This situation is not a normal usecase anway, in which case error instead of crash sounds viable.

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 13, 2019):

Okay so I have been trying this out for a while now, and I couldnt make it crash. However, I also didn't see any error message regarding this issue, ist just kept working.
To double check I tried with the old version, and it crashed again.

So either your fix did it, but doesnt give an error message, or anything else between my orignal version and yours might have fixed it.

I might add that in my original version I also had the issue that I am unable to switch playlists once playback started, and I had to reconnect my device to start a different song. I also dont have that issue with your version now, so I am double happy :)

@patrickjane commented on GitHub (Mar 13, 2019): Okay so I have been trying this out for a while now, and I couldnt make it crash. However, I also didn't see any error message regarding this issue, ist just kept working. To double check I tried with the old version, and it crashed again. So either your fix did it, but doesnt give an error message, or anything else between my orignal version and yours might have fixed it. I might add that in my original version I also had the issue that I am unable to switch playlists once playback started, and I had to reconnect my device to start a different song. I also **dont** have that issue with your version now, so I am double happy :)

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@kingosticks commented on GitHub (Mar 13, 2019):

I made it a warning message rather than an error - there is an argument that libraries shouldn't output stuff by default - but librespot (the program, not the library) does by default display warning messages for this module so if the fix was triggered you should have seen the message. So yeh, sounds like my fix hasn't helped but rather something else in the latest code has. However, I can't see what that could be since the offending line is explicitly identified in the original stacktrace and the file hasn't otherwise changed in a long time. I am confused.

It sounds like your switching playlist issue was https://github.com/librespot-org/librespot/issues/288

@kingosticks commented on GitHub (Mar 13, 2019): I made it a _warning_ message rather than an error - there is an argument that libraries shouldn't output stuff by default - but librespot (the program, not the library) [does by default display warning messages for this module](https://github.com/librespot-org/librespot/blob/master/src/main.rs#L72) so if the fix was triggered you should have seen the message. So yeh, sounds like my fix hasn't helped but rather something else in the latest code has. However, I can't see what that could be since the offending line is explicitly identified in the original stacktrace and the file hasn't otherwise changed in a long time. I am confused. It sounds like your switching playlist issue was https://github.com/librespot-org/librespot/issues/288

kerem commented

2026-02-27 19:29:21 +03:00

Author

Owner

@patrickjane commented on GitHub (Mar 14, 2019):

Okay, made some more tries, here it is:

INFO:librespot: librespot 6a60059 (2019-03-13). Built on 2019-03-13. Build ID: Qg84Srb4
WARN:librespot_connect::discovery: Login error for user "patrickjane": MAC mismatch
WARN:librespot_connect::discovery: Login error for user "patrickjane": MAC mismatch

👍

@patrickjane commented on GitHub (Mar 14, 2019): Okay, made some more tries, here it is: ``` INFO:librespot: librespot 6a60059 (2019-03-13). Built on 2019-03-13. Build ID: Qg84Srb4 WARN:librespot_connect::discovery: Login error for user "patrickjane": MAC mismatch WARN:librespot_connect::discovery: Login error for user "patrickjane": MAC mismatch ``` 👍

Rows
Columns

[GH-ISSUE #289] Crash upon connect #195