GNOME Bugzilla – Bug 589676
Disabling application monitoring causes endless loop
Last modified: 2009-08-28 16:36:12 UTC
I haven't had time to track down the exact code but shortly after disabling usage monitoring for gnome-shell in gconf I would find gnome-shell becoming completely unresponsive and mutter spinning at 100% cpu utilization. Strace showed mutter endlessly looping on inotify calls looking trying to look in home diectories of other users on my machine. Re-enabling the gconf key fixed the shell hanging problem. I promise to get more accurate test data, but wanted to file a bug before I forgot.
Created attachment 139414 [details] [review] Save-timer-id-to-remove-it-later-in-app-monitor Looking for obvious causes to that bug, I've discovered a little problem that can lead to the timer not being removed. Then strange things could happen, possibly including the timer being added once again on every call. But I can guarantee that's the fix. Could you try this patch?
I'm tempted to just remove the gconf key entirely; I don't see why we need it. This code was rewritten in bug 588343 regardless.
I was thinking we needed a way to avoid saving data about app usage, for privacy's sake. That was very to complex to have then. But if we rely on the app monitor to track running apps and show them in the overlay, we can't compeltely stop tracking now this now. Maybe the option should just disable saving stats.
Comment on attachment 139414 [details] [review] Save-timer-id-to-remove-it-later-in-app-monitor It's hard to see how this bug would have triggered an inotify infinite loop. Though without having the old code in front of me, it's hard to say what damage exactly could have been triggered. It's possible that removing random sources could have broken something inside GIO related to file monitoring. (Which is used for the user switching.) The key seems mostly harmless to me, and I'm not sure I'd bother ripping it out, though I don't foresee adding any UI to control it. There is one bug somewhat related to the one that Milan was fixing here in the current code. I'll attach a patch. There's one
Created attachment 141115 [details] [review] Clear save_id when removing idle_save_application_usage() When we remove the timeout for saving application usage when application usage is disabled, set the save_id member variable to 0.
Going to resolve this as FIXED, since it's OK as far as we know now, though we never quite tracked down what was going on.