Bug 426345 - mixer_applet2 always uses 100% CPU after resume
mixer_applet2 always uses 100% CPU after resume
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-applets (Show other bugs)
8
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-20 04:29 EST by Mads Kiilerich
Modified: 2008-05-27 17:55 EDT (History)
0 users

See Also:
Fixed In Version: Fedora 9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-27 17:55:59 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)

  None (edit)
Description Mads Kiilerich 2007-12-20 04:29:05 EST
Description of problem:
mixer_applet2 always uses 100% CPU after resume. Except for that sound works
fine (Rhythmbox and mplayer).

Version-Release number of selected component (if applicable):
gnome-applets-2.20.0-8.fc8

How reproducible:
on my machine 100% reproducible

Steps to Reproduce:
1. suspend to ram
2. resume
3. top
  
Actual results:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
                                                                               
                                                 
29005 mk        20   0 61020  13m 9.9m S   99  0.7  42:50.24 mixer_applet2     
                                                                               
                                                 

Killing the process causes gnome to restart it - and then it works again.

Expected results:
reasonable CPU usage

Additional info:
I mentioned the problem on bug 395581 #7 - but now it gets its own entry

Attaching gdb to mixer_applet2:

(gdb) thread apply all bt

Thread 2 (Thread -1222325360 (LWP 2853)):
#0  0x00110402 in __kernel_vsyscall ()
#1  0x00687ac3 in __poll (fds=0x712ff4, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:87
#2  0x00cf1576 in task_monitor_alsa (data=0x85a3400) at gstalsamixer.c:405
#3  0x00174eb6 in gst_task_func (task=0x83f6a90, tclass=0x8642580) at gsttask.c:192
#4  0x0050b2b8 in g_thread_pool_thread_proxy (data=0x8642610) at gthreadpool.c:265
#5  0x0050972f in g_thread_create_proxy (data=0x8642700) at gthread.c:635
#6  0x0075050b in start_thread () from /lib/libpthread.so.0
#7  0x00691b2e in clone () from /lib/libc.so.6

Thread 1 (Thread -1208591776 (LWP 2849)):
#0  0x00110402 in __kernel_vsyscall ()
#1  0x00687ac3 in __poll (fds=0x712ff4, nfds=10, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:87
#2  0x004e9583 in g_main_context_iterate (context=0x83eb508, block=1,
dispatch=1, self=0x83c4530) at gmain.c:2996
#3  0x004e98f9 in IA__g_main_loop_run (loop=0x83f50f8) at gmain.c:2898
#4  0x002d8813 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#5  0x002d6a79 in bonobo_generic_factory_main_timeout () from
/usr/lib/libbonobo-2.so.0
#6  0x002d6b03 in bonobo_generic_factory_main () from /usr/lib/libbonobo-2.so.0
#7  0x001c6101 in panel_applet_factory_main_closure () from
/usr/lib/libpanel-applet-2.so.0
#8  0x001c61e5 in panel_applet_factory_main () from /usr/lib/libpanel-applet-2.so.0
#9  0x0804f083 in gtk_vscale_new ()
#10 0x005d4390 in __libc_start_main (main=0x804ef70 <gtk_vscale_new+13524>,
argc=3, ubp_av=0xbfa17bc4, init=0x80504e0 <gtk_vscale_new+19012>, fini=0x80504d0
<gtk_vscale_new+18996>, 
    rtld_fini=0x5ad940 <_dl_fini>, stack_end=0xbfa17bbc) at libc-start.c:220
#11 0x0804bcb1 in gtk_vscale_new ()
(gdb) c


But I noticed:

[root@dev-mk ~]# ll /proc/2849/fd
total 0
lrwx------ 1 mk mk 64 2007-12-14 10:57 0 -> /dev/null
lrwx------ 1 mk mk 64 2007-12-14 10:57 1 -> /dev/null
lrwx------ 1 mk mk 64 2007-12-14 10:57 10 -> socket:[18745]
lrwx------ 1 mk mk 64 2007-12-14 10:57 11 -> socket:[18747]
lrwx------ 1 mk mk 64 2007-12-14 10:57 12 -> socket:[18750]
lrwx------ 1 mk mk 64 2007-12-14 10:57 13 -> socket:[18754]
lrwx------ 1 mk mk 64 2007-12-14 10:57 14 -> socket:[18751]
lrwx------ 1 mk mk 64 2007-12-14 10:57 15 -> socket:[18790]
lrwx------ 1 mk mk 64 2007-12-14 10:57 16 -> socket:[18791]
lr-x------ 1 mk mk 64 2007-12-14 10:57 17 -> pipe:[18895]
l-wx------ 1 mk mk 64 2007-12-14 10:57 18 -> pipe:[18895]
lrwx------ 1 mk mk 64 2007-12-14 10:57 19 -> /dev/snd/controlC0 (deleted)
lrwx------ 1 mk mk 64 2007-12-14 10:57 2 -> /dev/null
lrwx------ 1 mk mk 64 2007-12-14 10:57 3 -> socket:[18740]
lr-x------ 1 mk mk 64 2007-12-14 10:57 4 -> pipe:[18742]
l-wx------ 1 mk mk 64 2007-12-14 10:57 5 -> pipe:[18742]
lr-x------ 1 mk mk 64 2007-12-14 10:57 6 -> pipe:[18743]
l-wx------ 1 mk mk 64 2007-12-14 10:57 7 -> pipe:[18743]
lr-x------ 1 mk mk 64 2007-12-14 10:57 8 -> pipe:[18744]
l-wx------ 1 mk mk 64 2007-12-14 10:57 9 -> pipe:[18744]
[root@dev-mk ~]# ll /dev/snd/controlC0 
crw-rw----+ 1 root root 116, 6 2007-12-14 10:26 /dev/snd/controlC0
[root@dev-mk ~]# lsof /dev/snd/controlC0 
[root@dev-mk ~]# ll /dev/snd/controlC0 
crw-rw----+ 1 root root 116, 6 2007-12-14 10:26 /dev/snd/controlC0
[root@dev-mk ~]# top

Has /dev/snd/controlC0 been deleted and created again by HAL, and now the mixer
is busy talking to a device that doesn't exist? It shouldn't use 100% anyway.
Comment 1 Mads Kiilerich 2008-01-25 10:00:20 EST
Problem remains in kojis gnome-applets-2.20.1-1.fc8
Comment 2 Mads Kiilerich 2008-05-27 17:55:59 EDT
IIRC recent Fedora 8 updates have fixed it. It definitely works for Fedora 9.
Closing.

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