Created attachment 4776 Patch to demonstrate mouse wheel case I'm using xfce4-mixer with a USB Headset and OSS. When the slider is moved all the way down or the volume is reduced to 0 with the mouse wheel the pannel becomes unresponsive and CPU utilization goes up to 100%. I was able to prevent the mouse wheel case with the following test case (see patch). This patch only handles the mouse wheel. The slider would have to be handled too.
(In reply to comment #0) > Created attachment 4776 > Patch to demonstrate mouse wheel case > > I'm using xfce4-mixer with a USB Headset and OSS. When the slider is moved > all the way down or the volume is reduced to 0 with the mouse wheel the > pannel becomes unresponsive and CPU utilization goes up to 100%. I was able > to prevent the mouse wheel case with the following test case (see patch). > This patch only handles the mouse wheel. The slider would have to be handled > too. The GtkAdjustment value is clamped between 0.0 and 1.0, it cannot become negative, so the problem must be triggered when it becomes exactly 0.0. Since I can't reproduce this on my box I need some additional information. First, please attach the output of xfce4-mixer --debug. Then please follow the panel plugin debugging instructions at http://git.xfce.org/apps/xfce4-mixer/tree/README#n45 , reproduce the problem, quit the panel and attach the log file corresponding to the mixer plugin here. Finally, please reproduce the problem again and then attach to the mixer plugin process with gdb and get a full backtrace (with 'thread apply all backtrace full', note that xfce4-mixer must have been built with debug symbols and not stripped) and attach it here so we can see where exactly it gets stuck.
Created attachment 4814 Output of xfce4-mixer --debug This is the output of xfce4-mixer --debug. Note, xfce4-mixer itself does not crash when the sliders (both: volume and pcm) are moved all the way up and down, only the panel plugin slider.
Created attachment 4815 Output of various PANEL_DEBUG options Output of PANEL_DEBUG with the values: mixer, gdb, display-layout. Note that if xfce4-panel is started with PANEL_DEBUG=gdb, the panel starts but doesn't load the xfce4-mixer icon. It can then also not be added as it is listed but the add button is disabled.
Created attachment 4816 Compressed output of truss while crash This is the output of truss -o xfce4-panel.truss -f xfce4-panel. You can see that the panel loads, the slider is moved all the way down and the slider becomes unresponsive. The following process then has to be killed with SIGKILL from the console. After that xfce-panel is stoped with -q. The process killed on the console: minime 84235 53.1 0.3 238528 24212 1 R+ 2:58PM 0:07.32 /usr/loca l/lib/xfce4/panel/wrapper /usr/local/lib/xfce4/panel/plugins/libmixer.so 3 25165 854 mixer Audio Mixer Adjust volume levels
(In reply to comment #3) > Created attachment 4815 > Output of various PANEL_DEBUG options > > Output of PANEL_DEBUG with the values: mixer, gdb, display-layout. Note that > if xfce4-panel is started with PANEL_DEBUG=gdb, the panel starts but doesn't > load the xfce4-mixer icon... That's strange, however not a problem here since it doesn't actually crash instantly it doesn't need to wrapped with gdb. I just noted that the a part of the README is actually wrong about the PANEL_DEBUG value, sorry about that. Can you start xfce4-panel with PANEL_DEBUG=xfce4-mixer-plugin (rather than PANEL_DEBUG=mixer)? This should print some information when the plugin receives gstreamer messages or is interacted with. (In reply to comment #4) > Created attachment 4816 > Compressed output of truss while crash > > This is the output of truss -o xfce4-panel.truss -f xfce4-panel. You can see > that the panel loads, the slider is moved all the way down and the slider > becomes unresponsive. The following process then has to be killed with > SIGKILL from the console. After that xfce-panel is stoped with -q. > > The process killed on the console: > minime 84235 53.1 0.3 238528 24212 1 R+ 2:58PM 0:07.32 > /usr/loca > l/lib/xfce4/panel/wrapper /usr/local/lib/xfce4/panel/plugins/libmixer.so 3 > 25165 > 854 mixer Audio Mixer Adjust volume levels Could you attach gdb to this process once it gets stuck and produce a full backtrace with 'thread apply all backtrace full' so we can see where in the plugin code it is busy-looping?
Created attachment 4817 Compressed output of PANEL_DEBUG=xfce4-mixer-plugin xfce4-panel This is the compressed output of: PANEL_DEBUG=xfce4-mixer-plugin xfce4-panel
Created attachment 4818 gdb trace attached to the haning process: thread apply all backtrace full Output of gdb attached to the process: gdb> thread apply all backtrace full
Thanks, I can now see where it is busy looping, I'll look into this over the next days.
From looking at the code I don't see why it gets into this loop, particularly as there are guards suppressing notifications while modifying gstreamer and widget states in order to prevent feedback loops between the plugin and widget code. I've refactored the code a bit, moving the auto-mute logic from the widget into the plugin code in order to avoid an unnecessary widget updates. Can you check git master if it changes anthing (though I wouldn't expect it to)? What happens if you mute the track from the buttons context menu or when you lower the volume using XF86LowerVolume (if you have that key)? Does this only happen with your USB headset or also with any other sound hardware you have? I need to reproduce this and step through the code to see why it gets into this loop.
Closing old bugs.