mixer_applet2 often gets in 100% cpu use scenerio

[David Nielsen]

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)]

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.

[David Nielsen (davidnielsen-deactivatedaccount)]

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

[Hardik Dalwadi (hardik-dalwadi)]

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

[Hardik Dalwadi (hardik-dalwadi)]

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 :)

[David Nielsen (davidnielsen-deactivatedaccount)]

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)]

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

Problem:
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

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 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 ()
(gdb)
--

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

[Sebastien Bacher (seb128)]

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

[Hardik Dalwadi (hardik-dalwadi)]

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)]

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

[Hardik Dalwadi (hardik-dalwadi)]

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.

[Hardik Dalwadi (hardik-dalwadi)]

Attached the Upstream Bug URL

[Sebastien Bacher (seb128)]

Thank you for sending the bug there

[Andreas Berger (andi-berger)]

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)]

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)]

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

[Dries Harnie (dharnie)]

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.