Created attachment 135481 [details] gdb backtrace Description of problem: pulseaudio aborts unexpectedly at sink-input.c several times per day. Version-Release number of selected component (if applicable): pulseaudio-11.1 How reproducible: I do not use any audio devices. I have no audio devices connected to the audio outputs. I do not use audio at this machine at all, but pulseaudio aborts regularly several times per day. Steps to Reproduce: 1) wait about one hour for pulseaudio to quit unexpectedly Actual results (from syslog): Nov 09 08:28:44 gklab-124-124 pulseaudio[8775]: [pulseaudio] sink-input.c: Assertion 'PA_SINK_INPUT_IS_LINKED(i->state)' failed at pulsecore/sink-input.c:1883, function pa_sink_input_finish_move(). Aborting. Expected results: pulseaudio does not abort unexpectedly Additional info: $ ps aux | grep pulseaudio gdm 1284 0.0 0.0 1248200 11024 ? S<l 13:03 0:00 /usr/bin/pulseaudio --start --log-target=syslog ldorau 10241 0.6 0.0 1285868 12124 ? S<l 14:49 0:00 /usr/bin/pulseaudio --start --log-target=syslog
Created attachment 135482 [details] journalctl log with debug log level
See the report in RH bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1511516
It happened __103__ times on my machine during the last month.
Marking as a release blocker.
Alsa is reporting that headphones are repeatedly plugged in and out, and that makes pulseaudio switch between headphones and spdif output. I'd guess that's a hardware defect. You can work around the problem by commenting out module-switch-on-port-available in /etc/pulse/default.pa. That will stop the output switching. The crash seems to happen when a stream (in this case a bell sound from gnome shell) stops during an output switch. I don't know how that's possible, I'll continue investigation later.
I think the problem is that the sink input is unlinked somewhere between pa_sink_move_all_start() and pa_sink_move_all_finish(). The simple solution is to check the state of the sink input in pa_sink_move_all_finish() and ignore the sink input if it is already unlinked. A patch for this can be found here: https://patchwork.freedesktop.org/patch/191580/. Could you test if this fixes the issue? However, I am not sure if this is the right way to solve the problem. Tanu, what do you think?
(In reply to Georg Chini from comment #6) > However, I am not sure if this is the right way to solve the problem. Tanu, > what do you think? The patch seems good. I still wonder what's really happening here, though. I think it's not possible for the stream to end during the profile switch, because after detaching from the old sink, no more audio is consumed from the stream before it's attached to the new sink. Does something call pa_sink_input_kill()?
I checked all pa_sink_input_unlink() and pa_sink_input_kill() calls, and I didn't notice anything that could cause a sink input to be unlinked while it's being moved, so it looks like this crash should be impossible... Oh well, there's a fix and the fix seems sensible in any case, so I'm not going to spend more time on this (unless it's reported that the fix doesn't help).
Please see also this bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1472285
I can test any debug/test version - if you want to, just let me know.
(In reply to Tanu Kaskinen from comment #5) > Alsa is reporting that headphones are repeatedly plugged in and out, and > that makes pulseaudio switch between headphones and spdif output. I'd guess > that's a hardware defect. You can work around the problem by commenting out > module-switch-on-port-available in /etc/pulse/default.pa. That will stop the > output switching. > Of course I do not plug in or out anything, so it really can be a hardware defect. I have just commented out the 'load-module-switch-on-port-available' in /etc/pulse/default.pa. Let's see if it helps...
It would be good if you could also verify that PA does not crash anymore with the patch applied and without disabling module-switch-on-port-available. The patch is in master now, so you can use current git.
It is not easy to verify this patch. The bug reproduces only with the binary pulseaudio-11.1-6.fc26 rpm installed. I have built the pulseaudio-11.1-6.fc26 package from sources and the bug does not reproduce. It does not reproduce also with pulseaudio built from the git repo without the patch. I tested the new pulseaudio-11.1-7.fc26 binary package with the patch and it works well.
Thanks for the information, Lukasz. Georg's patch is now in master, I'll close this bug.
Thanks for the fix!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.