Closed YHNdnzj closed 2 years ago
MaxKellermann
commented
2 years ago Your backtrace shows that the crash occurs inside a thread created by libpipewire, and only libpipewire code is involved here, nothing MPD specific. This doesn't look like a MPD bug, but a PipeWire bug. Sorry, I can't help.
MaxKellermann
commented
2 years ago See also https://github.com/MusicPlayerDaemon/MPD/issues/1376 and https://github.com/MusicPlayerDaemon/MPD/issues/1464 for other PipeWire crash bugs mistakenly reported here.
YHNdnzj
commented
2 years ago Your backtrace shows that the crash occurs inside a thread created by libpipewire, and only libpipewire code is involved here, nothing MPD specific. This doesn't look like a MPD bug, but a PipeWire bug. Sorry, I can't help.
Thanks for the quick response. Just checked that someone has created an issue in PipeWire's repo (https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2488). I'll keep track of that instead.
saivert
commented
2 years ago The crash is caused by this code in MPD:
static void ControlInfo(void *data,
uint32_t id,
const struct pw_stream_control *control) noexcept {
auto &o = *(PipeWireOutput *)data;
if (StringIsEqual(control->name, "Channel Volumes"))
o.ControlInfo(control);
}control->name can now be NULL for some reason. This is a regression or a breaking change in API on pipewire's side.
A possible fix would be to compare against id instead:
if (id == SPA_PROP_channelVolumes) ...When I wrote this code I didn't know id was the prop id and the API documentation doesn't say anything either. You still have to read source code of pipewire to understand what is going on sadly.
MaxKellermann
commented
2 years ago The crash reported here is not caused by this code in MPD.
saivert
commented
2 years ago It fixed the same type of crash for the pipewire plugin for DeaDBeeF. Crash occurs in the strcmp code because it compares against a NULL. And the control_info event handler is called from the thread spawned by libpipewire. Crash happens at stream.c line 1308 which is pw_stream_emit_control_info macro call which eventually expands into a direct call to the event handler function. Because of lack of debug symbols you don't see the event handler function name in the backtrace.
But we have figured out why pipewire sends NULL strings and it will get fixed upstream so we can just sit tight.
Bug report
Describe the bug
After upgrading pipewire to 0.3.53, mpd dumps core every time on startup after loading decoder. Previously it starts and plays fine, although it can't remember the volume as to #1484.
Switching output type to
pulsesolves both of the problems.Version
Backtrace using GDB
Configuration
https://github.com/YHNdnzj/dotfiles/blob/master/mpd/.config/mpd/mpd.conf