1.0.77 core dumps

[prometheanfire]

Sections from running --show-console

00:48:26.394 D [gaia_manager.cpp:1121           ] GAIA: TIMING(144864044) GaiaManager::onSubscriptionSuccess
00:48:26.395 D [gaia_manager.cpp:1266           ] GAIA: TIMING(144864045) GaiaManager::sendHelloHelper
00:48:28.733 E [cdn_chunk_downloader.cpp:266    ] CDN failure 0->524288. Error: http_error_connect_timeout (1). Http: 0.
00:48:28.733 I [cdn_chunk_downloader.cpp:93     ] Requesting data (0 -> 524288) from CDN url: http://audio4-ak.spotify.com.edgesuite.net/audio/1d2efa254d8c86fdfa48e9f52d77fe368a95547e?__token__=exp=1523584105~hmac=f8e59ee1958392092e3cde24a903d911deaf770b1ca2ac56b4d71c3993d03d62 
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  set_option: Cannot assign requested address
Aborted (core dumped)

00:48:26.394 D [gaia_manager.cpp:1121           ] GAIA: TIMING(144864044) GaiaManager::onSubscriptionSuccess
00:48:26.395 D [gaia_manager.cpp:1266           ] GAIA: TIMING(144864045) GaiaManager::sendHelloHelper
00:48:28.733 E [cdn_chunk_downloader.cpp:266    ] CDN failure 0->524288. Error: http_error_connect_timeout (1). Http: 0.
00:48:28.733 I [cdn_chunk_downloader.cpp:93     ] Requesting data (0 -> 524288) from CDN url: http://audio4-ak.spotify.com.edgesuite.net/audio/1d2efa254d8c86fdfa48e9f52d77fe368a95547e?__token__=exp=1523584105~hmac=f8e59ee1958392092e3cde24a903d911deaf770b1ca2ac56b4d71c3993d03d62 
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  set_option: Cannot assign requested address
Aborted (core dumped)

It looks like the new libcurl stuff isn't working anymore

[prometheanfire]

00:48:25.333 I [dns.cpp:60                      ] resolved apresolve.spotify.com to 104.154.127.47
00:48:25.338 D [gaia_manager.cpp:1109           ] GAIA: TIMING(144862989) GaiaManager::sendSubscribe
00:48:25.351 E [ad_state_pusher.cpp:183         ] ad_state_pusher error: config request error message=ap_network_disabled
00:48:25.351 E [proxy_ad_requester.cpp:90       ] proxy-ad-requester error: config request error - 39
00:48:25.351 E [proxy_ad_requester.cpp:90       ] proxy-ad-requester error: config request error - 39
00:48:25.351 E [proxy_ad_requester.cpp:90       ] proxy-ad-requester error: config request error - 39
00:48:25.351 I [gaia_hermes_channel.cpp:92      ] GAIA: GaiaHermesChannel::send, failed query

[jschuck9]

I'm experiencing the same issue, I've temporarily downgraded to 0.917.8.gd06432d7.

[jschuck9]

I'm on Unbuntu 16.04.3 LTS

[rot13]

I have same issue. Ubuntu 17.04.

[prometheanfire]

I've had my comment deleted, not sure why, maybe it has too much debugging info and the mods don't like that?

https://bugs.gentoo.org/653042#c14 has the info

The problem I had was that spotify is trying to place a multicast address on a tun device.  tun devices don't support multicast.  This caused the coredump/crash.

My current workaround is to make sure spotify starts before the tun device is created (stop my VPN in my case, then restart it after spotify is started up).

[user-removed]

I am on Ubuntu 16.04.4 LTS and get the same error regarding proxy-ad-requester.

[jooon]

I tried setting up a tunnel with a tun device, but I have not been able to reproduce this problem. I did however find a recently introduced call (between 1.0.72 and 1.0.77) to a boost socket set_option that doesn't properly handle errors.

The error handling bug has been fixed in 1.0.79, which has been uploaded to the snap candidate channel and to the testing debian repository. I hope this fixes the issue.

Multicast is used in mDNS that is used to discover other Spotify devices so you can control them with Spotify connect. There is no use setting it on devices that doesn't support, because it won't find any devices anyway.

[prometheanfire]

Thanks for that.  It sounds like that may be the fix.  I don't see 1.0.79 yet, but when I do I'll test.  I am looking at the following url for the testing repo, not sure if it's correct anymore.

http://repository.spotify.com/pool/non-free/s/spotify-client/

[rot13]

1.0.79 works fine for me.

Thank you!

[jooon]

---

@prometheanfire wrote:

Thanks for that.  It sounds like that may be the fix.  I don't see 1.0.79 yet, but when I do I'll test.  I am looking at the following url for the testing repo, not sure if it's correct anymore.

http://repository.spotify.com/pool/non-free/s/spotify-client/

---

The domain and path is correct, but that specific address is a directory view, which APT itself never uses to fetch files. It gets the location from the Packages file.

http://repository.spotify.com/dists/testing/non-free/binary-amd64/Packages

/pool is cached by the CDN for a long time, because that's where the big deb files are. The files themselves never change, they are only added and eventually removed.

/dists is cached for a very short time, because those files change and they need to be in sync with eachother.

If you want to go directly to the web server that the CDN uses for upstream, go to:

https://repository-origin.spotify.com/pool/non-free/s/spotify-client/

Then you also get https on a spotify.com domain which is easier to trust.

[prometheanfire]

Thanks for the url, I just tried the new version and am getting the same error.  I wonder if it's because I have a v6 address on the tun device (I know not everyone pushes v6 routes, but I do).

[jooon]

Do you get exactly the same boost exception as before or a different one?

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
  what():  set_option: Cannot assign requested address

In which case, does the LD_PRELOAD workaround from the other thread work?

https://community.spotify.com/t5/Desktop-Linux/Spotify-apt-hangs-on-startup-in-Ubuntu-18-04/m-p/4462...

[prometheanfire]

Yep, the LD_PRELOAD worked for me