mixer_applet2 often gets in 100% cpu use scenerio

Bug #339187 reported by David Nielsen on 2009-03-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNOME Applets
Nominated for Main by Hardik Dalwadi
gnome-applets (Ubuntu)
Ubuntu Desktop Bugs
Declined for Jaunty by Sebastien Bacher

Bug Description

top reports
 4145 david 20 0 279m 26m 12m S 99 1.3 109:50.79 mixer_applet2

There seem to be other reports of this but there where closed saying a fix was released. However it still happens to me on Jaunty as of Mar 07 2009.

Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a backtrace following the instructions at http://wiki.ubuntu.com/DebuggingProgramCrash and upload the backtrace (as an attachment) to the bug report. This will greatly help us in tracking down your problem.

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete

It's not a crash, so capturing a backtrace doesn't seem like an option. Please advise

Hardik Dalwadi (hardik-dalwadi) wrote :

I am also facing the same problem, PFA for detail info while utilizing 100% by mixer_applet2.

Hardik Dalwadi (hardik-dalwadi) wrote :

Currently, I can get out of this bug by killing the process manually.

#sudo killall -9 mixer_applet2

Then, gnome-applets will ask you to reload it again, Press "Reload", it should solve your problem. But just work around :)

That won't even workaround it, eventually it will get into that pattern again and joyfully continue it's 100% cpu load madness when I turn my back and leave the room. Regardless because of the poor way Ubuntu handles bugs and other personal reason I have switched to Fedora so please request further information from Hardik Dalwadi

Hardik Dalwadi (hardik-dalwadi) wrote :

Now, i can reproduce this bug consistently (Most of the time). Please find the step below to reproduce it.

mixer_applet2 is utilizing 100% CPU usage after doing resume. Sound is working fine.

Step to reproduce:
1. Just do suspend
2. Then resume
3. Observer the "top" utility.

#top -p 4508 -d 3

top - 12:58:11 up 1:20, 3 users, load average: 1.05, 1.28, 1.37
Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
Cpu(s): 37.3%us, 20.7%sy, 0.0%ni, 41.7%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st
Mem: 3095632k total, 1498188k used, 1597444k free, 63628k buffers
Swap: 4000144k total, 0k used, 4000144k free, 825724k cached

 4508 person 20 0 55436 19m 14m S 100 0.6 17:34.82 mixer_applet2

Actual Result:
mixer_applet2 is taking 100 CPU usage

Expected Result:
CPU usage should be reasonable.

Debug Information:

(gdb) thread apply all bt

Thread 2 (Thread 0xb68bab90 (LWP 4520)):
#0 0xb806b430 in __kernel_vsyscall ()
#1 0xb7830ae7 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb68c2914 in task_monitor_alsa (data=0x9405790) at gstalsamixer.c:440
#3 0xb7fe3593 in gst_task_func (task=0x916ee88, tclass=0x93adbc0) at gsttask.c:192
#4 0xb7938cd6 in g_thread_pool_thread_proxy (data=0x93adc50) at /build/buildd/glib2.0-2.20.0/glib/gthreadpool.c:265
#5 0xb793766f in g_thread_create_proxy (data=0x94bccb8) at /build/buildd/glib2.0-2.20.0/glib/gthread.c:635
#6 0xb78c04ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7 0xb783b49e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb6cef750 (LWP 4508)):
#0 0xb806b430 in __kernel_vsyscall ()
#1 0xb7830ae7 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb791d61b in IA__g_poll (fds=0x9170790, nfds=11, timeout=-1) at /build/buildd/glib2.0-2.20.0/glib/gpoll.c:127
#3 0xb790fe52 in g_main_context_iterate (context=0x9147758, block=1, dispatch=1, self=0x912b838) at /build/buildd/glib2.0-2.20.0/glib/gmain.c:2761
#4 0xb791048a in IA__g_main_loop_run (loop=0x916dfe8) at /build/buildd/glib2.0-2.20.0/glib/gmain.c:2656
#5 0xb7e98cc3 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#6 0xb7e96e89 in bonobo_generic_factory_main_timeout () from /usr/lib/libbonobo-2.so.0
#7 0xb7e96f13 in bonobo_generic_factory_main () from /usr/lib/libbonobo-2.so.0
#8 0xb7f6962d in panel_applet_factory_main_closure (iid=0x8051f2c "OAFIID:GNOME_MixerApplet_Factory", applet_type=152493328, closure=<value optimized out>)
    at panel-applet.c:1742
#9 0xb7f6971b in panel_applet_factory_main (iid=0x8051f2c "OAFIID:GNOME_MixerApplet_Factory", applet_type=152493328,
    callback=0x80501f0 <gnome_volume_applet_factory>, data=0x0) at panel-applet.c:1766
#10 0x080501b4 in main (argc=1, argv=0xbfe898b4) at load.c:175
#0 0xb806b430 in __kernel_vsyscall ()

Observation, Extra Information:
It happens mostly after doing Suspend/Resume activity.

Changed in gnome-applets (Ubuntu):
status: Incomplete → New
Sebastien Bacher (seb128) wrote :

could you open the bug on bugzilla.gnome.org since you get the issue?

Hardik Dalwadi (hardik-dalwadi) wrote :

Neither i have filed any bug to bugzulla.gnome.org nor i have found the same one on that. Is it upstream bug? Do you want me to open new bug on that?

Sebastien Bacher (seb128) wrote :

the bug is an upstream one yes and should be sent to bugzilla by somebody having the issue if possible or a bug triager

Bug reported to upstream [http://bugzilla.gnome.org/show_bug.cgi?id=578254]. Here is another Bug #150089, but it was happened in different case, it was already in fixed-release status. I have already tested that bug, it's working fine in my case.

Attached the Upstream Bug URL

Changed in gnome-applets:
status: Unknown → New
Sebastien Bacher (seb128) wrote :

Thank you for sending the bug there

Changed in gnome-applets (Ubuntu):
status: New → Triaged
Andreas Berger (andi-berger) wrote :

I also get this bug:
If the mixer applet is set to "C-Media USB Headphone Set (Alsa Mixer)" mixer_applet2 goes to 100% CPU after resume.
Nothing happens if it is set to PulseAudio Mixer of the same USB device or Alsa Mixer or PulseAudio Mixer of internal soundcard.

Head Geek (chad-thecomfychair) wrote :

I'm seeing exactly the same problem, also with the "C-Media USB Headphone" device. Anything I can do to help get this resolved?

Stefano Prenna (stefanoprenna) wrote :

My Jaunty with a Logitech USB Headset has the same issue. Any news about this issue?

Dries Harnie (dharnie) wrote :

I just wrote up a description of the bug upstream.

Short version:
The ALSA plugin for the GST framework that mixer_applet uses, still looks at the old device nodes for the ALSA mixer. These nodes are deleted upon suspend (or hibernate) but the ALSA plugin is unaware of this. the poll() function used returns immediately with an error code instead of properly blocking, which causes the mixer_applet to use 100% CPU.

So it's an GST bug, not a gnome-applets one.

Changed in gst-plugins-base:
status: Unknown → New
Changed in gst-plugins-base:
importance: Unknown → Medium
Changed in gnome-applets:
importance: Unknown → Critical
Changed in gst-plugins-base:
status: New → Unknown
Changed in gst-plugins-base:
status: Unknown → Invalid
Changed in gnome-applets:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.