GNOME Bugzilla – Bug 686502
gnome-shell becomes unresponsive
Last modified: 2013-05-15 14:17:02 UTC
Created attachment 226861 [details] [review] proposed patch I noticed that in some cases gnome-shell started using 100% just after startup, which seemingly coincided with the Empathy roster application. After some more research this turned out to be triggered by the remote menu. Every time the _modelChanged function runs through the model it will connect to action-added for every item which is in the model but not in the action group. The callback for the action-added signal forces a refresh of the whole model, which means all items that haven't been added yet will now have one more signal handler connected. In my case Empathy has a quite a few items in its menu (caused by the amount of favourite rooms is have), which meant that the amount of signal handlers spirals out of control causing gnome-shell to become unresponsive for long periods of time.
Created attachment 226863 [details] [review] fixed patch
Review of attachment 226863 [details] [review]: The original idea was to have at most one signal per menu hierarchy, as we don't rebuild the whole module, just the submenu containing the unknown item, so could you try adding a check in line 1965 and not connect a signal if one was added for a sibling?
(In reply to comment #2) > The original idea was to have at most one signal per menu hierarchy, as we > don't rebuild the whole module, just the submenu containing the unknown item, > so could you try adding a check in line 1965 and not connect a signal if one > was added for a sibling? Is there a good reason to not just rebuild the whole menu or is it just premature optimization? This code is pretty hairy already so I'd rather go for a working fix making it simpler rather than even more complicated. :)
*** Bug 681539 has been marked as a duplicate of this bug. ***
This has been fixed with the GtkMenuTracker port.
*** Bug 700364 has been marked as a duplicate of this bug. ***