esound causes desktop session to hang

Thank you, for the bug report. Which version of Ubuntu did you install? Which
language settings did you choose in the installation? Did anything weird happen
during the installation? Does this always happen? Can you do anything after you
logged in?

Same behaviour here for Ubuntu 5.10 (Breezy Badger). Language set to es_ES.
Installation ran smooth and got Gnome working like a charm. After a couple of
(clean) reboots, the usual session login drops me into a blank screen as
described --white pointer that can be moved around -to no avail since there is
nothing to point or click- on a brown background. You can't do anything after
login except Ctrl-Alt-Backspace to get back to login and change session parameters.

Workaround: restart the session in console safe mode. I did apt-get update &&
apt-get install fluxbox since i thought the problem could be related to the
window manager. Voilá, that gave me back nice decorations for my windows and
functionality for some applications (e.g. firefox would not launch but dillo
would).
The important bit was to do apt-get upgrade The whole Xorg system seemed to need
an update. Now running Xorg 6.8.2-69 and everything is fine, even Metacity. BTW:
I've seen this also happen in a recent Debian installation (which also included
Xorg).

(In reply to comment #2)
> The important bit was to do apt-get upgrade The whole Xorg system seemed to need
> an update. Now running Xorg 6.8.2-69 and everything is fine, even Metacity. BTW:
> I've seen this also happen in a recent Debian installation (which also included
> Xorg).

Thanks for that information - <email address hidden> could you try that too?

do you have ubuntu-desktop installed? can you ping 127.0.0.1?

I believe this is being caused by ESD. I was experiencing the same behavior on
login (background appears, nothing else happens), and by starting using the
failsafe xterm session and then manually starting x-session-manager and then
stracing gnome-panel, i found it was waiting on an ESD socket. Once I killed
the running ESD (and then disabled it under Gnome), everything's working
beautifully.

Moral of this story: there's a reason people have been talking about replacing
ESD for sixty billion years.

Mike.

Martin: can I have your advise on this?

This sounds like bug #18545, which has been fixed long ago, though. What is your
esound version?

While Gnome hangs, can you please change to a console (Ctrl+Alt+F1), login, and
send the output of

  strace -p $(pidof esd)

? While you do this, please check if the Gnome session continues to load while
strace runs (You can switch to X with Alt+F7).

I agree this sounds exactly like the other bug. I'm going to reinstall (this
was just a scratch install, anyway) so I can get you the exact information
you're looking for. Should be later today.

(In reply to comment #7)
> What is your esound version?

esound is 0.2.36-1ubuntu5.

> While Gnome hangs, can you please change to a console (Ctrl+Alt+F1), login, and
> send the output of
>
> strace -p $(pidof esd)

Attached.

> ? While you do this, please check if the Gnome session continues to load while
> strace runs (You can switch to X with Alt+F7).

Nope. Unlike the other bug, stracing esd doesn't appear to make any difference.

Nor does installing libesd0 in place of libesd-alsa0.

A further possible data point---I'm guessing there's supposed to be a sound
played when gdm start up, but I get a stuttering, low-frequency noise rather
than any sort of pleasing sound. Perhaps this is related? I'm installing on an
IBM T22 thinkpad that has had Debian on it for the last four years, with a
cs46xx sound chipset.

Created an attachment (id=4168)
strace of esd

(In reply to comment #8)
> I agree this sounds exactly like the other bug. I'm going to reinstall (this
> was just a scratch install, anyway) so I can get you the exact information
> you're looking for. Should be later today.

Has the problem been fixed now? Or what is the status?

(In reply to comment #11)
> (In reply to comment #8)
> > I agree this sounds exactly like the other bug. I'm going to reinstall (this
> > was just a scratch install, anyway) so I can get you the exact information
> > you're looking for. Should be later today.
>
> Has the problem been fixed now? Or what is the status?

Err, see comments #9 and #10, which stated that the problem continued and was
not ameliorated by the things that had helped with the prior esd issue.

First, a question: if you purge esound completely, and use gstreamer-properties
to switch the gstreamer output to ALSA instead of esd, does it work as it
should? This could help to determine whether the bug is in ALSA or in esd.

Thanks for the indeed interesting strace. The ioctl(6, 0x400c4150, ...)
sometimes produces an error, and finally hangs. However, there are no ioctl's in
esound (nor the library) that could be responsible for this, so the ioctl must
be from the ALSA library.

When esd hangs, can you please try to generate a stack trace?

  gdb /usr/bin/esd $(pidof esd)

when in gdb, enter "bt" to get a stack trace. Please copy it here.

Thanks!

(In reply to comment #13)
>
> When esd hangs, can you please try to generate a stack trace?
>
> gdb /usr/bin/esd $(pidof esd)
>
> when in gdb, enter "bt" to get a stack trace. Please copy it here.

mdorman@amanda:~$ gdb /usr/bin/esd $(pidof esd)
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

Attaching to program: /usr/bin/esd, process 28144
(no debugging symbols found)
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
Reading symbols from /lib/libwrap.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libwrap.so.0
Reading symbols from /usr/lib/libesd.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libesd.so.0
Reading symbols from /usr/lib/libaudiofile.so.0...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libaudiofile.so.0
Reading symbols from /lib/tls/i686/cmov/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libm.so.6
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/tls/i686/cmov/libnsl.so.1...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libnsl.so.1
Reading symbols from /usr/lib/libasound.so.2...
(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libasound.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...(no debugging symbols
found)...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...
(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread -1211377984 (LWP 28144)]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7e5de29 in ioctl () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d2064e in _snd_pcm_hw_open () from /usr/lib/libasound.so.2
#3 0xb7d0fd88 in snd_pcm_writei () from /usr/lib/libasound.so.2
#4 0xb7f151ba in esd_audio_write () from /usr/lib/libesd.so.0
#5 0x0804c51c in clean_exit ()
#6 0x0804a9fe in clean_exit ()
#7 0xb7db1ea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#8 0x08049751 in ?? ()
(gdb)

(In reply to comment #13)
> First, a question: if you purge esound completely, and use gstreamer-properties
> to switch the gstreamer output to ALSA instead of esd, does it work as it
> should? This could help to determine whether the bug is in ALSA or in esd.

If I use gstreamer-properties and turn off esd, everything works, though I have
to admit that I'm not sure what this accomplishes---with esd removed, everything
works, regardless.

Or did you mean, kill rather than purge?

> Thanks for the indeed interesting strace. The ioctl(6, 0x400c4150, ...)
> sometimes produces an error, and finally hangs. However, there are no ioctl's in
> esound (nor the library) that could be responsible for this, so the ioctl must
> be from the ALSA library.

The backtrace I already replied with certainly makes it look like it's libalsa.

(In reply to comment #15)
> If I use gstreamer-properties and turn off esd, everything works, though I have
> to admit that I'm not sure what this accomplishes---with esd removed, everything
> works, regardless.

Good to hear. This is in fact the solution we aim at for Dapper. It completely
avoids the silly desktop sound daemon and directly uses the dmix plugin of ALSA.
It just happens to fail on many cards, which is why we used esound for Breezy by
default.

> Or did you mean, kill rather than purge?

It does not make much of a difference. But you can as well purge the package if
you don't need it.

> The backtrace I already replied with certainly makes it look like it's libalsa.

Right, thanks for the BT. Thomas, did you ever see this?

I will forward this to the ALSA bug tracking system, but it is down at the moment.

(In reply to comment #16)
> (In reply to comment #15)
> > The backtrace I already replied with certainly makes it look like it's libalsa.
>
> Right, thanks for the BT. Thomas, did you ever see this?

I recall that some bugs were fixed in esd's ALSA output code not too long ago.
What version of libesd-alsa0 are people using when they experience the problem?

The new sound backend is now implemented in Breezy, i. e. for the majority of
people esound should not be used at all. This should mitigate these problems
considerably.

*** Bug 21987 has been marked as a duplicate of this bug. ***

Is that still an issue for you in dapper? The autospawn change of esound, and
the new gstreamer backend in general should avoid this kind of problem.

No answer for four months. In dapper, this problem should be vastly mitigated since esd is not used by default any more. Please reopen this bug if you still encounter problems. Thank you!

I just had to killall esd on feisty.

Should I reopen this bug?

I had this twice today on feisty. Reopening.

I second this for feisty.

I can reliably reproduce this on feisty as of the date of this comment.

The system logs in, gnome splashes and then the session load halts.

A quick ps x | grep esd shows
15060 ? Ss 0:00 /bin/sh -c /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 24
15061 ? SL 0:00 /usr/bin/esd -terminate -nobeeps -as 1 -spawnfd 24

Which leads me to believe that bug #86162 may also be related.
Killing off both esd instances lets gnome-session to continue loading.

same problem here with just installing feisty in a vmware ESX guest OS (no sound card).

The desktop session startup hangs. ~/.xsession-errors reports lots of no sound card found information.

Indeed the recent gutsy version dropped all Ubuntu patches. They need to be reapplied to fix this.

esound (0.2.38-0ubuntu2) gutsy; urgency=low

  * Previous upload dropped all Debian and Ubuntu patches. Reintroduce the
    critical ones for Tribe 3 for now:
    - esd.conf: Enable autospawn mode.
    - esddsp.c: Protect dsp_init() with a mutex to prevent race conditions
      from multiple calls (which hanged the desktop session). (LP: #21915)

 -- Martin Pitt <email address hidden> Wed, 18 Jul 2007 12:03:22 +0200

I've lost my desktop and access to the menus
all I've got is my mouse..
I was trying to fix the sound on my dell xps 1330 laptop that came pre-installed with ubuntu
I made the following commands..

killall pulseaudio
sudo aptitude remove pulseaudio
sudo aptitude install esound
sudo aptitude remove /etc/X11/Xsession.d/70pulseaudio

https://help.ubuntu.com/community/Skype#Message:%20%22Problem%20with%20...%22

I've read through the commands above and can't see the solution yet..

could someone please spell out the commands?
what's the command to print the stack trace to a text file?