Closed sweetyoru closed 2 years ago
This looks like a crash in libspa/libpipewire and not related to MPD.
@wtay Pipewire is still killing mpd
@wtay Pipewire is still killing mpd
What version are you running? maybe try git master of pipewire?
@wtay Pipewire is still killing mpd
What version are you running? maybe try git master of pipewire?
It's crashing with the latest in F36.
pipewire-0.3.54-1.fc36
It's crashing with the latest in F36.
Ok, you will have to either downgrade or wait till the next version later this week.
Next version of mpd or pipewire?
next version of pipewire.
Thanks @wtay for dropping by and helping out. @sweetyoru PipeWire, I think. He's the PipeWire guy.
Bugs like this one are difficult to judge - what looks like a PipeWire bug can be a MPD bug after all, if MPD passes wrong parameters to libpipewire; this always needs a closer look. In this case, the backtrace shows that this happens inside a thread created by libpipewire, with only libpipewire (and libspa) on the stack. This makes it very unlikely to be caused by MPD.
We had other bug reports with incomplete backtraces that also looked like PipeWire bugs (e.g. https://github.com/MusicPlayerDaemon/MPD/issues/1558), but turned out to be MPD bugs; or rather a PipeWire version with a different behavior, with a null pointer where never was a null pointer before, and no documentation on whether a null pointer was allowed. Reality is sometimes more complex than desired ;-)
in this case I think it's pipewire fault. There was a bug in audioconvert where it would read more data then was available, which could explain this.
That is a write instruction, so maybe audioconvert guys also need to check for data write too.
That is a write instruction, so maybe audioconvert guys also need to check for data write too.
Yes, one end was reading too much, the other writing too much.
I can't run mpd myself so i can't test with the maser version of pipewire if it's fixed now. If you could test that would be great, otherwise we have to hope it's working in the next release (very soon).
That is a write instruction, so maybe audioconvert guys also need to check for data write too.
Yes, one end was reading too much, the other writing too much.
I can't run mpd myself so i can't test with the maser version of pipewire if it's fixed now. If you could test that would be great, otherwise we have to hope it's working in the next release (very soon).
I will need to wait for the new release to make it to fedora's repo, since messing with the package isn't a good idea. Thank you very much for the help.
@sweetyoru You can get the latest builds using
https://koji.fedoraproject.org/koji/buildinfo?buildID=2000504 https://ftp-stud.hs-esslingen.de/pub/Mirrors/rpmfusion.org/free/fedora/updates/testing/36/x86_64/repoview/letter_m.group.html
sudo dnf install koji;mkdir pipewire;cd pipewire;koji download-build --arch=x86_64 2000504;sudo dnf update *rpm
sudo dnf --enablrepo=r*g update mpd*
the f36 update: https://bodhi.fedoraproject.org/updates/FEDORA-2022-45a1c6b1c9
I can't reproduce the crash, so I can't confirm if the update work or not. Need to wait for others to bump into this.
Bug report
Describe the bug
Segfault due to write into read-only mapped memory.
Expected Behavior
Work normally.
Actual Behavior
Segfault.
Version
Configuration
Log
d.core.zip A core file is provided.
coredumpctl output: