GNOME Bugzilla – Bug 122327
Notification area takes 100% cpu
Last modified: 2011-02-04 16:12:10 UTC
Everything is GNOME 2.4.0. Try the following : -first start an application which displays a tray icon (pam-panel-icon or rhythmbox) -then, start gnome-panel, with a notification area watch your CPU : 25% for notification-area 25% for X 25% for application providing the tray icon 25% for gnome-panel Strangely, I don't get this when I downgrade from GTK+ 2.2.4 to 2.2.1 ...
More info on this bug : With GTK+ 2.2.4, if I give focus to notification-area manually (with mouse), the 100% cpu bug disappears. I might be caused by this GTK commit : Wed Aug 20 21:26:49 2003 Owen Taylor <otaylor@redhat.com> * gtk/gtkplug.c (gtk_plug_focus): Send the focus on to the parent when there was no focus widget before and no focus widget after - that is, when there are no focusable widgets. (#108678, help tracking it down from Padraig O'Briain, Federico Mena Quintero, ) adding owen for review
Well, I wouldn't be suprised if that change causes the problem - it was a fairly massive rewriting of focus-related code for GtkPlug/GtkSocket, fixing important problems. But without information about the details of what's going on on your system, I can't do anything to fix. If you still don't have a functioning gdb, what you can do is compile GTK+ with --enable-debug and then set GTK_DEBUG=plugsocket ... that should give you some useful debug output.
Created attachment 19945 [details] trace from pam-panel-icon
Created attachment 19946 [details] trace of notification-area
Created attachment 19947 [details] gnome-panel trace
I had to truncate log files because they all contains big chunks of similar output : the focus finder code is probably in a infinite loop..
OK, the problem seems to be in the notification area ... somehow, it's not sending the FOCUS_NEXT message on to the panel toplevel ... In gtksocket.c:advance_toplevel_focus(), could you add the debug spew: if (!GTK_WIDGET_TOPLEVEL (toplevel) || GTK_IS_PLUG (toplevel)) { + g_print ("Sending focus_next message on to plug toplevel\n"); gtk_widget_child_focus (toplevel,direction); return; } And in gtkplug.c:gtk_plug_focus() add /* We override GtkWindow's behavior, since we don't want wrapping here. */ + + g_print ("gtk_plug_focus: old_focus_child=%p\n", old_focus_child); + if (old_focus_child) { if (gtk_widget_child_focus (old_focus_child, direction)) return TRUE; And in gtksocket.c:gtk_socket_claim_focus() add: static void gtk_socket_claim_focus (GtkSocket *socket, gboolean send_event) { + g_Print ("gtk_socket_claim_focus(), send_event=%d\n", send_event); + if (!send_event) socket->focus_in = TRUE; /* Otherwise, our notify handler will send FOCUS_IN */
Created attachment 19950 [details] pam-panel-icon trace with verbose patched gtk
Created attachment 19951 [details] notification area trace with verbose patched gtk
Created attachment 19952 [details] gnome-panel trace with verbose patched gtk+
Sorry for the spam, I can't attach 3 files at the same time.. Again, I've put only partial traces since they are very big and are only repeating themselves..
A) I only need the debug spew from the notification area - the other two are behaving correctly B) It would be useful to have the GTK_DEBUG=plugsocket spew turned on as well for this But actually I have an idea here. Could you try the following patch to gtksocket.c:gtk_socket_focus() - if (!GTK_WIDGET_HAS_FOCUS (widget)) + if (!gtk_widget_is_focus (widget)) Thanks.
Created attachment 19953 [details] notification area log with plugsocket + verbose gtk
I've attached log of notification area WITHOUT your patch.. I've tested your patch and it FIXED the problem !! Is it a workaround for notification-area or a real fix for GTK ?
It's the real fix. The docs for gtk_widget_is_focus() should make clear why it is necessary. Determines if the widget is the focus widget within its toplevel. (This does not mean that the %HAS_FOCUS flag is necessarily set; %HAS_FOCUS will only be set if the toplevel widget additionally has the global input focus.)
*** Bug 122263 has been marked as a duplicate of this bug. ***
*** Bug 123762 has been marked as a duplicate of this bug. ***
So, can this bug be marked Resolved->fixed? I ask, because I have the same issue and it would be nice to see it go away. Magically, if possible. :)
Created attachment 20520 [details] [review] It works, it works! Formal patch.
It won't be marked RESOLVED/FIXED until the code has committed to CVS. That will be prior to the next stable release of GTK+.
I confirm this problem, as done on gnomesupport.org forum already. This problem also persists in GTK+ HEAD and should be solved there as well. At least acme behaves the same way with GTK+ HEAD.
Sorry for the spam everyone. This might be a dumb question, but is there a reason that this fix hasn't been commited to CVS yet?
*** Bug 127056 has been marked as a duplicate of this bug. ***
Committed to both stable and head. Thu Nov 20 15:48:03 2003 Soeren Sandmann <sandmann@daimi.au.dk> * gtk/gtksocket.c (gtk_socket_focus): Use gtk_widget_is_focus() instead of GTK_WIDGET_HAS_FOCUS. (#122327, Owen Taylor. Reported by Frederic Crozat).
*** Bug 127802 has been marked as a duplicate of this bug. ***
*** Bug 128322 has been marked as a duplicate of this bug. ***
*** Bug 130554 has been marked as a duplicate of this bug. ***
I just downloaded the source (gtk+-2.2.4)... looked at the source, and the code was still the old line... :X changed it... configure, make && make install... Restarted X.. I am still getting the 100% CPU utilization... Is there something I am missing? Thanks.
Yeah - it looks like it's targeted for 2.2.5. 2.2.4 was released 11 days before this bug was filed, much less fixed. The patch is in CVS now (http://cvs.gnome.org/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=gtksocket.c&branch=&root=/cvs/gnome&subdir=gtk%2b/gtk&command=DIFF_FRAMESET&rev1=1.58&rev2=1.59)
*** Bug 134521 has been marked as a duplicate of this bug. ***
*** Bug 136819 has been marked as a duplicate of this bug. ***