[pulseaudio-discuss] gnome-shell hangs, waiting for pulse-audio

[Tanu Kaskinen]

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
exist.

> 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 
> successfully.
> 
> 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.

-- 
Tanu