[pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio
tanuk at iki.fi
Tue Dec 4 04:41:54 PST 2012
On Tue, 2012-12-04 at 11:49 +0100, Henrik /KaarPoSoft wrote:
> On 12/04/12 04:32, Tanu Kaskinen wrote:
> > On Tue, 2012-12-04 at 03:47 +0200, Tanu Kaskinen wrote:
> >> Hmm... I checked when the operation state is set to DONE, and it's not
> >> done until after calling the callback. So, if the kernel schedules the
> >> main thread after the pa_threaded_mainloop_signal() call, but before the
> >> operation state is set to DONE, the main thread will get stuck. It's a
> >> bug in libcanberra. I'll try to come up with a patch for that.
> > I've attached a patch. Henrik, could you test it? libcanberra source
> > code can be retrieved with
> > git clone git://git.0pointer.de/libcanberra
> Thank you very much for the analysis and patch.
> I really appreciate your help on this.
> First, I removed the desktop-switch sound files again.
> Just for good measure, I tried this 3 times *without* the patch:
> - open gnome-terminal, press backspace twice to get two beeps
> - open firefox and play HTML5 video from youtube
> - close firefox, then close gnome-terminal
> In all three cases the desktop froze as expected.
> Now *with* the patch (and after reboot), I tried the above again.
> And you and behold, no freeze, and a big smile on my face.
> However, I repeated the steps immediatly (no logout or similar), and now
> the desktop froze )-:
> I rebooted and tried again.
> This time I had to repeat three times to get the freeze.
> Syslog and backtraces attached.
> So, I am guessing that you found the reason for the trouble, but that
> the patch did not manage to solve it.
No, I made an error in my analysis. The patch doesn't fix anything. The
pa_threaded_mainloop_wait() call won't be able to return until the
libpulse thread enters polling, and at that point the operation state
should be set properly, so the bug that I thought was there didn't
> A strange observation:
> When I press backspace the first time in gnome-terminal (*only* the
> first time, and *only* in the first gnome-terminal opened) it seems that
> I get *two* beeps (slightly overlapping).
> This seems to be consistent when running *with* the patch, but I never
> noticed it (although it might have been there) *without* the patch.
> Anyway, I have another problem, and I am starting to think that it is
> related to this one.
> Every now and again - maybe 1 out of 10 or 1 out of 20 - *without* the
> patch I experience this:
> gdm shows login screen
> I select my user and enter the password and press enter or click login
> The screen freezes for about a minute, and then the login continues
> Now *with* the patch, this seems to happen on roughly half of my logins!
Does the patch really cause this, or is the difference because of the
self-compiled libcanberra? That is, if you compile libcanberra without
the patch, does it return to the old behavior?
> syslog attached.
> When the login screen froze I switched to another Virtual Terminal and
> put WAITING in the syslog.
> You will find this around line 1182, just to give a time reference.
> It seems that gdm is telling "Client1" to die, but it does not die, and
> so gdm is timing out...
> As far as I can tell the "Client1" is the gnome-shell used by gdm, which
> is why I am guessing the problems are related.
> Any further help would be most appreciated.
I'll have a look at the logs soon, but it looks likely that you'll have
to add debug prints to libpulse and/or libcanberra to figure out what is
going wrong. I guess the most interesting question is: does
play_sample_cb in libcanberra get called?
Hmm, here's another idea: could you try marking the state field of
pa_operation as volatile? The pa_operation struct is defined in
src/pulse/internal.h. I expect that this won't help, but maybe the
compiler is able to do more optimization magic than I think is
possible... On a related note, the play_request_processed variable in my
patch should have been marked as volatile too.
More information about the pulseaudio-discuss