Bug 238680 - esd hangs the session on sound events
esd hangs the session on sound events
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: alsa-lib (Show other bugs)
rawhide
i386 Linux
urgent Severity high
: ---
: ---
Assigned To: Martin Stransky
:
: 230758 242059 242376 243068 243135 243546 243758 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-02 05:09 EDT by Sertaç Ö. Yıldız
Modified: 2007-11-30 17:12 EST (History)
19 users (show)

See Also:
Fixed In Version: 0.2.38-2.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-21 16:05:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
there's a patch to esound (352 bytes, patch)
2007-06-11 06:35 EDT, Martin Stransky
no flags Details | Diff
backtrace of esd from my hung session (2.78 KB, text/plain)
2007-06-15 01:06 EDT, Bryan Che
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 431711 None None None Never

  None (edit)
Description Sertaç Ö. Yıldız 2007-05-02 05:09:56 EDT
This might be a bug in another component, but esd looks like the most common
component.

Description of problem:

With FC7t3 and FC7t4 based installations when esound and system sounds are
enabled, gnome-session cannot start (hangs after playing the login sound) unless
esd is killed from a vty.

With current rawhide and esound-svn session can occasionally start. But usually
the first program launched hangs again. 


Additional info:

* system-config-souncard can play the sound sample when esd is not running. But
when esd is running (and the session did not hang) soundcard detection cannot
play the sample sound. It's calling aplay with "-D plughw:0,0" parameter. I can
manually play the sample without this parameter.

* Hanging programs are stalled at esd_send_auth() call in esd_open_sound().

* gstreamer threading issues were mentioned in the related fedora-test-list
thread (
https://www.redhat.com/archives/fedora-test-list/2007-April/msg00377.html ). So
this might also be relevant. gnome-sound-properties spits a warning on start-up:

 GStreamer-WARNING **: The GStreamer function gst_init_get_option_group() was
        called, but the GLib threading system has not been initialised
        yet, something that must happen before any other GLib function
        is called. The application needs to be fixed so that it calls
           if (!g_thread_supported ()) g_thread_init(NULL);
        as very first thing in its main() function. Please file a bug
        against this application.
Comment 1 Christian Anthon 2007-05-07 06:31:33 EDT
I'm having this issue as well. Seems that other distributions are struggling
with similar issues. Any word of advice? It would be nice to have this fixed
before FC 7 is released.

Christian. 
Comment 2 Bastien Nocera 2007-05-08 10:10:53 EDT
Is more than one copy of esound running when you see that problem? Could you
please test with esound-0.2.38-1 I pushed to rawhide today?

If the problem persists, could you please attach a backtrace of the hang, with
the appropriate -debuginfo packages installed?
Comment 3 Sertaç Ö. Yıldız 2007-05-08 10:37:04 EDT
(In reply to comment #2)
> Is more than one copy of esound running when you see that problem?

nope, there's only one esd process.

> Could you
> please test with esound-0.2.38-1 I pushed to rawhide today?

esound-svn I mentioned was essentially 0.2.38. I cannot see the new package on
the mirrors yet but the problem exists with 0.2.38 packages I've built myself.

> If the problem persists, could you please attach a backtrace of the hang, with
> the appropriate -debuginfo packages installed?

I've attached backtraces of both esd and a hanged gnome-panel to:
http://bugzilla.gnome.org/show_bug.cgi?id=431711 . Are they good enough?
Comment 4 Bastien Nocera 2007-05-10 12:12:23 EDT
Which version of alsa-lib and the kernel are you using?

The same bug was report in ALSA's bug tracker:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
and it's supposed to have been fixed in the kernel drivers version 1.0.9a

If it still happens, it's probably a bug in the driver/ALSA kernel-side.
snd_pcm_wait_nocheck shouldn't be hanging...
Comment 5 Sertaç Ö. Yıldız 2007-05-10 13:14:29 EDT
(In reply to comment #4)
> Which version of alsa-lib and the kernel are you using?

Currently alsa-lib-1.0.14-0.4.rc3.fc7 on kernel-PAE-2.6.21-1.3142.fc7

> The same bug was report in ALSA's bug tracker:
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
> and it's supposed to have been fixed in the kernel drivers version 1.0.9a

Yes, I saw it mentioned on a ubuntu bug too, but this problem didn't exist with
FC6. Checking the dmesg outputs between fc6 and fc7 kernels, with fc6 I had this
message:
hda_codec: Unknown model for ALC861, trying auto-probe from BIOS...

With fc7 I have this instead:
hda_intel: azx_get_response timeout, switching to polling mode...

> If it still happens, it's probably a bug in the driver/ALSA kernel-side.
> snd_pcm_wait_nocheck shouldn't be hanging...

I also think this is alsa related. I've filed this agains esd partly because I
don't have any sound problems (that i'm aware of) besides this esd hang issue,
and partly because I considered esd hanging the session for whatever reason
being a bug on its own.
Comment 6 Bastien Nocera 2007-05-10 18:43:49 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Which version of alsa-lib and the kernel are you using?
> 
> Currently alsa-lib-1.0.14-0.4.rc3.fc7 on kernel-PAE-2.6.21-1.3142.fc7

Should be more than new enough.

> > The same bug was report in ALSA's bug tracker:
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1306
> > and it's supposed to have been fixed in the kernel drivers version 1.0.9a
> 
> Yes, I saw it mentioned on a ubuntu bug too, but this problem didn't exist with
> FC6. Checking the dmesg outputs between fc6 and fc7 kernels, with fc6 I had this
> message:
> hda_codec: Unknown model for ALC861, trying auto-probe from BIOS...
> 
> With fc7 I have this instead:
> hda_intel: azx_get_response timeout, switching to polling mode...

That's probably not right...

> > If it still happens, it's probably a bug in the driver/ALSA kernel-side.
> > snd_pcm_wait_nocheck shouldn't be hanging...
> 
> I also think this is alsa related. I've filed this agains esd partly because I
> don't have any sound problems (that i'm aware of) besides this esd hang issue,
> and partly because I considered esd hanging the session for whatever reason
> being a bug on its own.

esd isn't hanging because of its own fault, it's hanging because
snd_pcm_wait_nocheck is hanging. snd_pcm_wait_nocheck shouldn't hang, and that's
a driver and/or alsa-lib problem.

As for the applications hanging, as mentioned on the upstream bugzilla, it's a
shortcoming of the esound architecture, there's no easy way to fix it,
unfortunately.

Reassigning to alsa-lib for first pass at debugging. Martin, do you think it
smells like a driver problem?
Comment 7 Martin Stransky 2007-05-16 07:51:06 EDT
It's hard to say. What ALSA device does the esd use? hw or plughw? It definitely
should use the "default" device which provides HW/SW mixing and so on.
Comment 8 Bastien Nocera 2007-05-17 10:46:09 EDT
I believe it uses "hw" by default, so it might be something else using the
device as well. Which devices would Sertaç need to grep for in lsof to see what
other app is using the sound device?

Should it simply use plughw instead?
Comment 9 Ray Strode [halfline] 2007-05-17 10:47:05 EDT
Adding Cameron to the report, because he hit this today.
Comment 10 Cameron Meadors 2007-05-17 11:48:58 EDT
I see this same thing when I have esd and play system sound enabled.  As for
hardware I have Intel ICH6 with AD1981B.  
Comment 11 Sertaç Ö. Yıldız 2007-05-17 13:36:14 EDT
esd defaults to "hw", and neither using plughw with "esd -d" nor updating
alsa-lib to rc4 made any difference.

output of "/usr/sbin/lsof +D /dev/snd":
COMMAND     PID   USER   FD   TYPE DEVICE SIZE NODE NAME
gnome-set 12829 sertac   23u   CHR  116,8      4662 /dev/snd/controlC0
mixer_app 12840 sertac   17u   CHR  116,8      4662 /dev/snd/controlC0
esd       12852 sertac  mem    CHR  116,6      4649 /dev/snd/pcmC0D0p
esd       12852 sertac    5r   CHR  116,2      4072 /dev/snd/timer
esd       12852 sertac    6u   CHR  116,6      4649 /dev/snd/pcmC0D0p
esd       12852 sertac    7u   CHR  116,8      4662 /dev/snd/controlC0
Comment 12 Bastien Nocera 2007-06-06 12:41:49 EDT
*** Bug 242059 has been marked as a duplicate of this bug. ***
Comment 14 David 2007-06-06 18:06:26 EDT
This does fix the issue until its properly resolved...

edit /etc/esd.conf
change
default_options=
to
default_options=-nobeeps -unix -as 2
Comment 15 Bastien Nocera 2007-06-07 04:42:35 EDT
*** Bug 243068 has been marked as a duplicate of this bug. ***
Comment 16 Sam Varshavchik 2007-06-09 14:08:50 EDT
As far as the original issue the esd daemon is having, that's one issue.  But
even if esd is malfunctioning, that by itself should not take the whole desktop
down with it.

I just suffered through an FC6 to FC7 upgrade, where the desktop failed to come
up at all.  I eventually discovered that a whole bunch of processes started by
gnome-session where hung in a connect() call to /tmp/.esd/socket, and nothing
would go any further until I kill esd, which had its socket open, but was not
accepting any connection.

After some peeking and poking, esd seems to be running after I manually deleted
$HOME/.esd_auth; unfortunately I did not keep a copy of the original file that
gave esd indigestion, however:

The problem is with the esound library.  It opens a connection to
/tmp/.esd/socket without employing any timeout whatsoever.  If esd gets stuck,
everyone will wait forever, to connect to esd, and the whole desktop freezes.

This is bad design.

The correct solution is to employ a reasonable timeout, say 10 seconds, and 
if the connection does not go through, give up and fall back to plan B.

Comment 17 Ray Strode [halfline] 2007-06-10 10:47:13 EDT
*** Bug 243135 has been marked as a duplicate of this bug. ***
Comment 18 Bill C. Riemers 2007-06-10 14:00:05 EDT
Boosting priority, since this bug makes Fedora 7 unusable to many users. 
Currently, this is one of two bugs blocking creating a Fedora 7 image for coLinux.
Comment 19 drago01 2007-06-10 14:02:18 EDT
(In reply to comment #14)
> This does fix the issue until its properly resolved...
> 
> edit /etc/esd.conf
> change
> default_options=
> to
> default_options=-nobeeps -unix -as 2
> 

this "fix" seem to work fine here thx.
Comment 20 Bastien Nocera 2007-06-11 05:15:42 EDT
*** Bug 243546 has been marked as a duplicate of this bug. ***
Comment 21 Martin Stransky 2007-06-11 06:34:45 EDT
there's probably a race condition in snd_pcm_drain. As a workaround, we can use
snd_pcm_drop.
Comment 22 Martin Stransky 2007-06-11 06:35:24 EDT
Created attachment 156695 [details]
there's a patch to esound
Comment 23 Bastien Nocera 2007-06-11 07:01:14 EDT
Test packages built against rawhide are available here (and in rawhide shortly):
http://koji.fedoraproject.org/koji/taskinfo?taskID=33235

Please test.
Comment 24 Sertaç Ö. Yıldız 2007-06-11 07:51:45 EDT
the patch in comment #22 solved the esd issue, thanks.

is there an open bug to track the original problem?
Comment 25 Bastien Nocera 2007-06-11 08:01:20 EDT
(In reply to comment #24)
> the patch in comment #22 solved the esd issue, thanks.
> 
> is there an open bug to track the original problem?

If that's the actual problem (a bug in alsa-lib or alsa core), we'll keep this
bug opened.
Comment 26 Bill C. Riemers 2007-06-11 09:31:21 EDT
Thanks.  I can also confirm the test packages from comment #23 solved the
problem for the two of my Fedora 7 installations.  (I have not checked the third
yet.)

Bill
Comment 27 Bastien Nocera 2007-06-12 05:44:32 EDT
*** Bug 243758 has been marked as a duplicate of this bug. ***
Comment 28 Bryan Che 2007-06-12 10:52:34 EDT
I installed the test package in comment #23.  This did not fix my problem.  I
enabled sounds, rebooted, and used my system.  That worked fine.  However, I
rebooted again, and then my login hung as before.
Comment 29 Bastien Nocera 2007-06-12 11:10:55 EDT
(In reply to comment #28)
> I installed the test package in comment #23.  This did not fix my problem.  I
> enabled sounds, rebooted, and used my system.  That worked fine.  However, I
> rebooted again, and then my login hung as before.

If the problem still occurs, could you please get a backtrace with the debuginfo
packages installed, as it's either the same problem (ie. hanging at the same
place), or there's another bug that needs to be worked on.
Comment 30 Bryan Che 2007-06-12 11:18:25 EDT
How do I get the backtrace?
Comment 31 Bastien Nocera 2007-06-12 11:36:33 EDT
(In reply to comment #30)
> How do I get the backtrace?

Following the instructions at:
http://fedoraproject.org/wiki/StackTraces

You'll probably need to install esound-debuginfo and alsa-lib-debuginfo
Comment 32 Cameron Meadors 2007-06-12 11:45:17 EDT
The patch package does not solve my problem.  Processes are still hanging when
playing sounds.  I would have a backtrace, but hard locks when switching to a
virtual console are blocking me (Lenovo T60).  
Comment 33 Martin Stransky 2007-06-12 11:48:57 EDT
when your system hangs, switch to the console (ctrl+alt+f1), search for pid of
esd process (ps axf) and attach gdb to it (gdb --pid=xxxx)
Comment 34 Matthew Barnes 2007-06-13 12:57:02 EDT
*** Bug 242376 has been marked as a duplicate of this bug. ***
Comment 35 Bryan Che 2007-06-15 01:06:56 EDT
Created attachment 157059 [details]
backtrace of esd from my hung session

This is a backtrace of esd on my hung login after enabling sound events.  I
have the patch from comment 23 applied.

esound-0.2.38-2.fc8.i386.rpm
esound-debuginfo-0.2.38-2.fc8.i386.rpm
Comment 36 Martin Stransky 2007-06-15 03:50:42 EDT
(In reply to comment #35)
> Created an attachment (id=157059) [edit]
> backtrace of esd from my hung session
> 
> This is a backtrace of esd on my hung login after enabling sound events.  I
> have the patch from comment 23 applied.

You don't use the patched version or the patch isn't applied right.
Comment 37 Bryan Che 2007-06-15 09:09:14 EDT
~/>rpm -qa | grep esound
esound-debuginfo-0.2.38-2.fc8
esound-libs-0.2.38-1.fc7
esound-0.2.38-2.fc8
esound-devel-0.2.38-1.fc7

OK, I see that there are additional esound rpm's: esound-libs and esound-devel.
 I'll install them and try again.
Comment 38 Bastien Nocera 2007-06-15 10:15:07 EDT
Can anybody else reproduce the problem with the updated packages?
If not, I'll push an F7 update, and file the bug upstream.
Comment 39 Bryan Che 2007-06-15 10:18:16 EDT
The patch seems to be working on my system now.
Comment 40 Cameron Meadors 2007-06-15 11:31:06 EDT
I can still reproduce the problem with the patched packages.  I will try to
provide backtraces, but other issues are making that difficult (hardlocks when
switching virtual consoles).
Comment 41 Cameron Meadors 2007-06-15 11:46:22 EDT
After a reboot, is seems the problem is resolved.  Maybe I had a stale process
hanging around or something.  Whatever.  It works now.
Comment 42 Fedora Update System 2007-06-16 09:22:48 EDT
esound-0.2.38-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 43 Bastien Nocera 2007-06-16 17:05:01 EDT
*** Bug 230758 has been marked as a duplicate of this bug. ***
Comment 44 Joachim Kunze 2007-06-18 01:31:36 EDT
I can also confirm, that the patched packages resolve the hang of esd after
login. One thing I encountered though was, that on one system (i386) esd hangs
again after a re-login. On my other x86_64 system esd works perfectly fine now.

Jo
Comment 45 Martin Stransky 2007-06-21 09:24:00 EDT
(In reply to comment #42)
> esound-0.2.38-2.fc7 has been pushed to the Fedora 7 testing repository.  If
problems still persist, please make note of it in this bug report.

Bastien, you may put this package into stable, not testing...
Comment 46 Bastien Nocera 2007-06-21 09:30:28 EDT
(In reply to comment #45)
> Bastien, you may put this package into stable, not testing...

Yeah, sounds like it's cooked. Pushed now.

Comment 47 Fedora Update System 2007-06-21 16:05:29 EDT
esound-0.2.38-2.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 48 drago01 2007-06-22 06:57:55 EDT
works fine, thx
Comment 49 Bas Driessen 2007-06-22 21:58:31 EDT
I am using Fedora 7 x86_64. After applying the esound-0.2.38-2.fc7 patch and
enabling the sound again, logging in is fine. However, my system now hangs when
logging out. The screen freezes, can't get any vty sessions, can't even logon
from another box using ssh. After disabling sounds, all is OK again. 

Anyone else with similar/same symptoms?

Please let me know what information I can provide to get this resolved.

Thanks,
Bas.
Comment 50 Bastien Nocera 2007-06-23 09:34:29 EDT
(In reply to comment #49)
> I am using Fedora 7 x86_64. After applying the esound-0.2.38-2.fc7 patch and
> enabling the sound again, logging in is fine. However, my system now hangs when
> logging out. The screen freezes, can't get any vty sessions, can't even logon
> from another box using ssh. After disabling sounds, all is OK again. 
> 
> Anyone else with similar/same symptoms?
> 
> Please let me know what information I can provide to get this resolved.

That's probably a kernel or X crash, nothing to do with this problem. Please
open a new bug about it, against the kernel.
Comment 51 Bas Driessen 2007-06-24 08:18:07 EDT
Well, if you say it has nothing to with this bug, fine with me. However  to me
it looks like there is some sort of a relation. I had exactly the same problem
when logging in with sound events enabled. After the 0.2.38-2 patch, logging in
is fine, but now I have exactly the same problem when logging out. If I disable
the sounds (the installation default) and booting, all works OK again and no
hangs whatsoever.

I have no idea how/where to log kernel/X bugs, so I guess I keep the sounds off
until someone else comes across it and Fedora 7 becomes a bit more stable.
Comment 52 Bastien Nocera 2007-06-24 09:22:02 EDT
(In reply to comment #51)
> Well, if you say it has nothing to with this bug, fine with me. However  to me
> it looks like there is some sort of a relation. I had exactly the same problem
> when logging in with sound events enabled. After the 0.2.38-2 patch, logging in
> is fine, but now I have exactly the same problem when logging out. If I disable
> the sounds (the installation default) and booting, all works OK again and no
> hangs whatsoever.

You're the first person to mention this particular problem, and esound shouldn't
hard-lock the machine, so it's unlikely to be directly related to this bug.

> I have no idea how/where to log kernel/X bugs, so I guess I keep the sounds off
> until someone else comes across it and Fedora 7 becomes a bit more stable.

File a bug, the assignee will surely be kind enough to point you in the right
direction.
Comment 53 Sertaç Ö. Yıldız 2007-06-24 10:03:12 EDT
Either the component or the status of this bug (but possibly both) are incorrect
at the moment.
Comment 54 Rodd Clarkson 2007-06-24 18:35:21 EDT
Nice to have this esd bug fixed finally.  Thanks.

I'm also having problems with my log out freezing and have filed a bug here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245522

Join me if this is an issue for you.

Note You need to log in before you can comment on or make changes to this bug.