FS#64414 - [curl] 7.67.0 makes mpd crash

Attached to Project: Arch Linux
Opened by Matthias Lisin (matthias.lisin) - Wednesday, 06 November 2019, 21:53 GMT
Last edited by Christian Hesse (eworm) - Monday, 11 November 2019, 14:31 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
New testing/curl 7.67.0-1 makes mpd crash when playing/pausing a https (mind the s) radio stream.
http streams work fine!

Signal: 11 (SEGV)

Two example streams I can reproduce it with:

* https://listen.moe/stream
* https://relay0.r-a-d.io/main.mp3

Packages used:

* testing/curl 7.67.0-1
* extra/mpd 0.21.16-1


Steps to reproduce:
1. install testing/curl 7.67.0-1
2. install extra/mpd
3. add https stream to your mpd playlist
4. play & pause stream
5. mpd crashes (SEGV)

Attachments:
- mpd (user) config

Will attach coredump as soon as I have build mpd and curl with debugging symbols. Backtrace is useless right now.
   mpd.conf (0.6 KiB)
This task depends upon

Closed by  Christian Hesse (eworm)
Monday, 11 November 2019, 14:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  curl 7.67.0-3
Comment by Matthias Lisin (matthias.lisin) - Wednesday, 06 November 2019, 22:06 GMT
Coredump file is too large to upload here (3.4M zstd-compressed)

Backtrace:

Thread 2 "io" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeac6a700 (LWP 61607)]
0x0000555555619cb2 in BindMethodDetail::BindMethodWrapperGenerator2<CurlGlobal, void (CurlGlobal::*)(), &CurlGlobal::ReadInfo, void>::Invoke(void*) ()

(gdb) bt
#0 0x0000555555619cb2 in BindMethodDetail::BindMethodWrapperGenerator2<CurlGlobal, void (CurlGlobal::*)(), &CurlGlobal::ReadInfo, void>::Invoke(void*) ()
#1 0x000055555561e6cb in EventLoop::HandleDeferred() ()
#2 0x000055555561e763 in EventLoop::OnSocketReady(unsigned int) ()
#3 0x0000555555620d41 in EventLoop::Run() ()
#4 0x000055555563d446 in BindMethodDetail::BindMethodWrapperGenerator2<EventThread, void (EventThread::*)(), &EventThread::Run, void>::Invoke(void*) ()
#5 0x000055555561de44 in Thread::ThreadProc(void*) ()
#6 0x00007ffff46b94cf in start_thread () from /usr/lib/libpthread.so.0
#7 0x00007ffff7ec82d3 in clone () from /usr/lib/libc.so.6
Comment by Jonas Witschel (diabonas) - Wednesday, 06 November 2019, 22:55 GMT
I am able to reproduce the crash with the following steps:

pacman -S mpd mpc

# in case there is no mpd configuration yet
mkdir ~/.config/mpd && cp -n /usr/share/doc/mpd/mpdconf.example ~/.config/mpd/mpd.conf

systemctl --user start mpd
mpc add https://listen.moe/stream
mpc play
mpc stop
systemctl --user status mpd

After downgrading to curl-7.66.0-1-x86_64.pkg.tar.xz the crash does not occur any more, so this seems to be a problem with the new curl version 7.67.0 indeed.
Comment by Dave Reisner (falconindy) - Thursday, 07 November 2019, 01:16 GMT
Ok, but what's the actual line of code that crashes? There's no interaction with curl on the crashing stack, so either curl is returning something unexpected which mpd stores and later fails to retrieve, or this is a latent bug (potentially related to multithreading) in mpd, exposed by a newer curl.
Comment by Matthias Lisin (matthias.lisin) - Thursday, 07 November 2019, 14:26 GMT
I'll try to find out where it crashes once I have some spare time. However I'm not familiar with debugging C applications, especially with all the threading around. So don't bet your money on it.
Comment by Dave Reisner (falconindy) - Thursday, 07 November 2019, 15:48 GMT
I can reproduce this, so I'll see what I can do.
Comment by Dave Reisner (falconindy) - Thursday, 07 November 2019, 16:17 GMT
Seems to me like a dangling reference in mpd code (due to a use after free). Opened a bug with mpd:

https://github.com/MusicPlayerDaemon/MPD/issues/681
Comment by Christian Hesse (eworm) - Friday, 08 November 2019, 23:27 GMT
To be continued here:
https://github.com/curl/curl/issues/4575
Comment by Matthias Lisin (matthias.lisin) - Monday, 11 November 2019, 13:07 GMT
Thanks to everyone involed in escalating it to upstream.
Are you going to keep testing/curl as is, apply the PR as a patch or wait until a new curl version with the fix is released?
Comment by Christian Hesse (eworm) - Monday, 11 November 2019, 13:14 GMT
We will push a patched version to testing. Waiting for the final commit thought, would like to have the correct commit hash in the patch.

Loading...