With curl being upgraded a few days ago mpd stopped working. View mpd.log: mpd: src/input/curl_input_plugin.c:268: input_curl_select: Assertion `max_fd >= 0' failed. masking and downgrading curl to 7.20.0 and recompiling mpd and all functions Reproducible: Always
The problem is, I believe, due to curl's new threaded DNS resolving feature, enabled with USE=threads. Current versions of mpd are incompatible with that feature, it would seem, and I just confirmed that adding an appropriate net-misc/curl -threads entry to package.use and remerging curl-7.21.0, "unbreaks" mpd, here. =:^) Technical details follow. A bit of googling on the error reported above lead me to this Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=599340 Comment #8 there in turn linked a discussion on the libcurl development list: http://thread.gmane.org/gmane.comp.web.curl.library/27709/focus=27721 The discussion is on a test from curl's test suite. Apparently, one of the previous test-suite tests was for max_fd (max file descriptor) >=0. The test wasn't part of the published API, however, so when they added threaded DNS resolution, they added a maxfd return value of "-1" as appropriate with the threaded implementation. Unfortunately, while not part of the documented API, the test from the test suite was adopted by certain users of the library, including mpd. That's the assertion in the log above, since libcurl with threading enabled returned -1, which obviously isn't going to pass a test for >=0. While the curl devs obviously weren't aware of mpd's usage, this post from the thread above all but confirms our issue: http://article.gmane.org/gmane.comp.web.curl.library/27725 Thus the logical (and confirmed here) Gentoo user-level temporary workaround, until mpd gets this fixed, should be an appropriate "net-misc/curl -threads" entry in package.use. As the curl feature is new, it's not like it's turning off functionality we had before or that anything can depend on yet, so unless someone's specifically testing the feature, it shouldn't be an issue for now. Meanwhile, I looked at mpd upstream and could find no mention of the issue in mantis (the bug tracker), the forums, or the git log, so they don't seem to be aware of it yet. After I register a mantis account upstream, I'll report the issue there, linking back here as well, and will then update here with a link there, too.
OK, here's the upstream bug: http://musicpd.org/mantis/view.php?id=2954
Created attachment 238033 [details, diff] patch proposed by upstream I rebuilt mpd with the attached patch as proposed upstream, rebuilt curl with USE=threads again, and so far, so good, tho I've only been using it with the patch a few minutes. Upstream says this will trigger a 1 second timeout and retry whenever max_fd=-1. I haven't tried to parse under what conditions that might be and the upstream comment didn't give any details, but if I understand the situation correctly, non-threaded libcurl and/or mpd would be operating abnormally if it ever occurs anyway, or the issue would have been seen before, and with threaded libcurl it should only occur at stream init, at which point a 1-second delay shouldn't be a big deal since there's already the normal connection init latency at that point anyway. So I don't expect any issues, but it's possible upstream will play with the timeouts a bit when they actually merge a patch, which would of course increase the complexity from this single line change. But meanwhile, this should be fine, it's definitely working, and even if there are occasional 1-second timeouts during connect, that's for sure better than the current situation of assertion forced shutdown, so I'd say patch it! The other alternative suggested by upstream is to simply delete that assertion line entirely, but I took the conservative approach and simply changed the assertion to allow for the -1 value. They can decide to delete the assertion entirely if they think it's of no value, but I'm not going to make that call on my own. We'll see what they actually merge. Duncan
Meanwhile <=media-sound/mpd-0.15.10 should possibly depend curl? ( net-misc/curl[-threads] ).
(In reply to comment #4) > Meanwhile <=media-sound/mpd-0.15.10 should possibly depend > curl? (net-misc/curl[-threads] ). No, because that doesn't deal with the case of curl before threading, which was only introduced (in Gentoo) with curl-7.21.0, which is ~arch, so wouldn't work for those still on stable curl-7.20.0-r2 or who haven't upgraded from the previous unstable 7.20.1. (This assumes that USE dependency atoms don't have an assumption of the flag being on if it's missing. No such assumption either way is mentioned in man 5 ebuild, at least, and it's best not to depend on behavior that isn't documented, even if it might happen to be the case with a particular version. Maybe it's documented in PMS, just not in the ebuild 5 manpage?) Thus, the dependency would have to be version-conditional. (If I didn't make some other mistake...) curl? || ( >=net-misc/curl-7.21.0[threads] <=net-misc/curl-7.21.0 ) Do note, however, that the Fedora/RH bug was for 7.20.x, so either they backported the threading feature, or it was introduced upstream earlier, and Gentoo simply didn't enable it. Either way it shouldn't matter for Gentoo, but it's a loose end I thought should be tied up, especially since this bug is now linked in upstream's bugtracker, so non-Gentoo users are likely to be reading it.
(In reply to comment #5) > Thus, the dependency would have to be version-conditional. (If I didn't make > some other mistake...) > > curl? || ( >=net-misc/curl-7.21.0[threads] > <=net-misc/curl-7.21.0 ) Ugh, I did! Two of them! Make that: curl? || ( >=net-misc/curl-21.0[-threads] <net-misc/curl-7.21.0 )
July 20th, 2010 - mpd-0.15.12 release MPD version 0.15.12 has been released. This release fixes MPD builds with recent CURL releases, RVA2 tags and adds wildmidi-0.2.3 support. gentoo@xmw.de: Please assign bugs according to the rules set out by the bug-wranglers project.
+*mpd-0.15.12 (22 Aug 2010) + + 22 Aug 2010; Markos Chandras <hwoarang@gentoo.org> +mpd-0.15.12.ebuild, + metadata.xml: + Version bump. Fixes bug #331471 and bug #326875 +
