GNOME Bugzilla – Bug 755425
NotificationMessage objects accumulate around a single Notification object
Last modified: 2015-10-08 00:44:06 UTC
Steps to reproduce: 1) open gnome-music 2) set in the background 3) listen to music, to increase effect, pause and skip songs sort of frequently, but always allow time to let notification banners above to disappear themselves 4) keep going on for a few days 5) close gnome-music, or just dismiss its notification from the calendar popup 6) gnome-shell can freeze for long periods of time, or even be left stuck dumping this endlessly to journald: ... sep 22 14:23:09 anacleto gnome-session[2009]: NotificationMessage<._init/<@resource:///org/gnome/shell/ui/calendar.js:1236 sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: Notification<.destroy@resource:///org/gnome/shell/ui/messageTray.js:481 sep 22 14:23:09 anacleto gnome-session[2009]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 sep 22 14:23:09 anacleto gnome-session[2009]: NotificationMessage<._init/<@resource:///org/gnome/shell/ui/calendar.js:1231 sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: Message<.close@resource:///org/gnome/shell/ui/calendar.js:1021 sep 22 14:23:09 anacleto gnome-session[2009]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 sep 22 14:23:09 anacleto gnome-session[2009]: NotificationMessage<._init/<@resource:///org/gnome/shell/ui/calendar.js:1236 sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: Notification<.destroy@resource:///org/gnome/shell/ui/messageTray.js:481 sep 22 14:23:09 anacleto gnome-session[2009]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 sep 22 14:23:09 anacleto gnome-session[2009]: NotificationMessage<._init/<@resource:///org/gnome/shell/ui/calendar.js:1231 sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: Message<.close@resource:///org/gnome/shell/ui/calendar.js:1021 sep 22 14:23:09 anacleto gnome-session[2009]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 sep 22 14:23:09 anacleto gnome-session[2009]: MessageListSection<.clear/<.onComplete@resource:///org/gnome/shell/ui/calendar.js:1445 sep 22 14:23:09 anacleto gnome-session[2009]: _addHandler/params[name]@resource:///org/gnome/shell/ui/tweener.js:91 sep 22 14:23:09 anacleto gnome-session[2009]: _callOnFunction@resource:///org/gnome/gjs/modules/tweener/tweener.js:203 sep 22 14:23:09 anacleto gnome-session[2009]: _updateTweenByIndex@resource:///org/gnome/gjs/modules/tweener/tweener.js:333 sep 22 14:23:09 anacleto gnome-session[2009]: _updateTweens@resource:///org/gnome/gjs/modules/tweener/tweener.js:345 sep 22 14:23:09 anacleto gnome-session[2009]: _onEnterFrame@resource:///org/gnome/gjs/modules/tweener/tweener.js:360 sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: ClutterFrameTicker<._onNewFrame@resource:///org/gnome/shell/ui/tweener.js:208 sep 22 14:23:09 anacleto gnome-session[2009]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169 sep 22 14:23:09 anacleto gnome-session[2009]: ClutterFrameTicker<._init/<@resource:///org/gnome/shell/ui/tweener.js:183 sep 22 14:23:09 anacleto gnome-session[2009]: (gnome-shell:2178): Gjs-WARNING **: JS ERROR: Exception in callback for signal: close: InternalError: too much recursion sep 22 14:23:09 anacleto gnome-session[2009]: _emit@resource:///org/gnome/gjs/modules/signals.js:124 sep 22 14:23:09 anacleto gnome-session[2009]: Message<.close@resource:///org/gnome/shell/ui/calendar.js:1021 ... It does seem like the NotificationMessage objects are left dangling and destroyed en masse when the Notification object is destroyed. I've found out the reason why this was happening, as mentioned in step #3 above, letting the banners disappear is crucial here, you'll get the _onDestroy() method being called, which disconnects from Notification::updated, but not from the "destroy" signal it's also connected to. This leaves the NotificationMessage in a sort of detached state, but still alive, and waiting for the Notification to be destroyed. I'm attaching a patch that fixes this by also disconnecting from the destroy signal, although this makes me wonder about the lifetime of older NotificationMessages, and whether I should care at all :).
Created attachment 311885 [details] [review] calendar: Disconnect all Notification signals on NotificationMessage destruction The destroy signal handler is kept connected despite the NotificationMessage being destroyed, which leaves dangling NotificationMessage objects that will be mass destroyed when the Notification object these depend upon is finally destroyed. Depending on the amount of accumulated NotificationMessages, this may lead to temporary freezes to other more funky issues when recursion limits are hit.
Review of attachment 311885 [details] [review]: Thanks for figuring that out! Both analysis and patch make sense to me.
Attachment 311885 [details] pushed as 409f671 - calendar: Disconnect all Notification signals on NotificationMessage destruction
NICE !
(as florian pointed out there, this seems likely to fix bug 749656 )
*** Bug 749656 has been marked as a duplicate of this bug. ***