Bug 189744 - esd blocks gnome desktop/ panel
Summary: esd blocks gnome desktop/ panel
Keywords:
Status: CLOSED DUPLICATE of bug 187959
Alias: None
Product: Fedora
Classification: Fedora
Component: esound
Version: 5
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Desktop
TreeView+ depends on / blocked
 
Reported: 2006-04-24 08:47 UTC by Thomas Steudten
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-06-06 16:12:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Thomas Steudten 2006-04-24 08:47:10 UTC
Description of problem:

Same like in FC4. Don't know why, but the esd sound daemon seems to block
some part of the gnome desktop/ panel, and/ or metactity.
E.g. you can mouse-click on the "Application Menu" on the upper panel, but
nothing happens. You can mouse-click on the firefox icon, nothing happens.

# ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     
0x2630b302 196608     thomas    600        1     

Semaphore Array semid=196608
uid=500  gid=500         cuid=500        cgid=500
mode=0600, access_perms=0600
nsems = 1
otime = Mon Apr 24 10:26:06 2006  
ctime = Mon Apr 24 10:26:06 2006  
semnum     value      ncount     zcount     pid       
0          1          0          1          2760 

# ps -ef | grep 2760
user    2760     1  0 Apr23 ?        00:00:00 /usr/bin/esd -terminate -nobeeps
-as 2 -spawnfd 18

# strace -p 2760
Process 2760 attached - interrupt to quit
semget(640725762, 1, IPC_CREAT|0600)    = 196608
semop(196608, 0xaf8b3b0e, 2

When I remove the semaphore, esd will create a new one, and when I remove this
too, all the processes come to live, which are blocking before (firefox, the
Application menu ..).

# strace -p 2760 (Removing the semaphore)
Process 2760 attached - interrupt to quit
semget(640725762, 1, IPC_CREAT|0600)    = 196608
semop(196608, 0xaf8b3b0e, 2)            = -1 EIDRM (Identifier removed)
semget(640725762, 1, IPC_CREAT|0600)    = 229376
semop(229376, 0xaf8b3b0e, 2)            = 0
shmget(403027995, 384, IPC_CREAT|0600)  = 425984
shmat(425984, 0, 0)                     = 0xa7f9f000
mlock(0xa7f9f000, 384)                  = 0
shmctl(425984, IPC_64|IPC_STAT, 0xaf8b3a58) = 0
open("/dev/snd/controlC0", O_RDONLY)    = 34
close(34)                               = 0
open("/dev/snd/controlC0", O_RDWR)      = 34
ioctl(34, USBDEVFS_CONTROL, 0xaf8b37c4) = 0
ioctl(34, 0x40045532, 0xaf8b37e4)       = 0
open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = -1 EBUSY (Device or resource busy)
close(34)                               = 0
write(2, "ALSA lib pcm_dmix.c:865:(snd_pcm"..., 44) = 44
write(2, "unable to open slave", 20)    = 20
write(2, "\n", 1)                       = 1
shmdt(0)                                = -1 EINVAL (Invalid argument)
shmdt(0xa7f9f000)                       = 0
shmctl(425984, IPC_64|IPC_STAT, 0xaf8b3a5c) = 0
nanosleep({0, 11000000}, NULL)          = 0
select(34, [4 5 12 14 16 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33], NULL,
NULL, {0, 0}) = 1 (in [1
2], left {0, 0})
accept(4, 0xaf8b4268, [16])             = -1 EAGAIN (Resource temporarily
unavailable)
select(34, [33], NULL, NULL, {0, 0})    = 0 (Timeout)
select(33, [32], NULL, NULL, {0, 0})    = 0 (Timeout)
select(32, [31], NULL, NULL, {0, 0})    = 0 (Timeout)
select(31, [30], NULL, NULL, {0, 0})    = 0 (Timeout)
select(30, [29], NULL, NULL, {0, 0})    = 0 (Timeout)
select(29, [28], NULL, NULL, {0, 0})    = 0 (Timeout)
select(28, [27], NULL, NULL, {0, 0})    = 0 (Timeout)
select(27, [26], NULL, NULL, {0, 0})    = 0 (Timeout)
select(26, [25], NULL, NULL, {0, 0})    = 0 (Timeout)

Seems that is problem with the ALSA sound. However the desktop/ gnome
should no block for a problem like this!

Version-Release number of selected component (if applicable):
esound-0.2.36-2.2.1

How reproducible:
Randomly, when another sound tool is playing.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
part of the desktop/ panel blocking.

Expected results:
No blocking if esd has a problem.

Additional info:

Comment 1 Thomas Steudten 2006-04-24 12:07:27 UTC
Killing esd also brings the application and desktop back to live.

Comment 2 Thomas Steudten 2006-05-11 12:24:07 UTC
No work here?

Comment 3 Ed Marshall 2006-07-19 13:25:10 UTC
I see the same behavior upon login on a fresh boot on my laptop. I can usually
trigger it by logging in very quickly once gdm is up. I haven't tried messing
with this yet, but I have ESD and "play system sounds" turned on in sound
preferences, if it makes a difference.

My normal course of action is usually to switch to a text terminal, kill off the
first/youngest esd process (there are always two), and login proceeds normally,
albeit without sound for that session.

Comment 4 Matthias Clasen 2006-07-31 17:40:08 UTC
Is this a problem in rawhide, too ?

Comment 5 Thomas Steudten 2006-08-02 09:34:02 UTC
I don't use rawhide. Very late reaction on this problem.

Comment 6 Thomas Steudten 2006-10-18 13:47:50 UTC
Looks like esd is starting up more than once, or after session closed (logout),
a new esd is starting up - and blocking the other one.

Comment 7 Bastien Nocera 2007-06-06 16:12:29 UTC

*** This bug has been marked as a duplicate of 187959 ***


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