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
