increase in number of wakeups in recent release in indicator-datetime

Bug #1296233 reported by Colin Ian King on 2014-03-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Indicator Date and Time
Fix Released
Charles Kerr
glib2.0 (Ubuntu)
indicator-datetime (Ubuntu)
Charles Kerr

Bug Description

The number of wakeup events has quadrupled in a recent release of indicator datetime on Trusty 14.04, so this looks like a minor regression.

In the previous set of runs it was down to ~2 wakeups a minute, now it's up to 8 again.

Attached is the output of a heath-check analysis of indicator-datetime-service showing the activity over 5 minutes. It seems that there is a poll occurring every 4 seconds which may be the root cause.

Related branches

Colin Ian King (colin-king) wrote :
Charles Kerr (charlesk) wrote :

Agreed, I'm seeing similar wakeup numbers when testing with 13.10.0+14.04.20140324.1-0ubuntu1.

Changed in indicator-datetime:
importance: Undecided → Medium
status: New → Confirmed
assignee: nobody → Charles Kerr (charlesk)
Charles Kerr (charlesk) wrote :

So, by adding a breakpoint for g_timeout_dispatch, it does look like gio's im_scan_missing is being called every four seconds. (glib/gio/inotify/inotify-missing.c's inotify_add() calls g_timeout_source_new_seconds(SCAN_MISSING_TIME) where SCAN_MISSING_TIME is #define'd to 4.

inotify-missing is watching for these directories to be created:

  * /usr/share/ubuntu/applications
  * /usr/local/share/applications

The backtrace shows that _im_add() is being called from this path:

#0 _im_add (sub=sub@entry=0x82d5d38) at /build/buildd/glib2.0-2.39.92/./gio/inotify/inotify-missing.c:60
#1 0xb7db2547 in _ih_sub_add (sub=sub@entry=0x82d5d38) at /build/buildd/glib2.0-2.39.92/./gio/inotify/inotify-helper.c:109
#2 0xb7db29ed in g_inotify_directory_monitor_start (local_monitor=0x828b038)
    at /build/buildd/glib2.0-2.39.92/./gio/inotify/ginotifydirectorymonitor.c:90
#3 0xb7da2f00 in g_local_directory_monitor_start (local_monitor=0x828b038)
    at /build/buildd/glib2.0-2.39.92/./gio/glocaldirectorymonitor.c:119
#4 0xb7d41acc in desktop_file_dir_init (dir=0x82a20c4) at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:847
#5 desktop_file_dirs_lock () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:939
#6 0xb7d43c9f in desktop_file_dirs_refresh () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:951
#7 mime_info_cache_init_dir_lists () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4086
#8 mime_info_cache_init () at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4130
#9 get_all_desktop_entries_for_mime_type (base_mime_type=base_mime_type@entry=0x82306c7 "text/calendar",
    include_fallback=include_fallback@entry=1, explicit_default=explicit_default@entry=0xbfffe96c, except=0x0)
    at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:4234
#10 0xb7d45ad9 in g_app_info_get_all_for_type (content_type=0x82306c7 "text/calendar")
    at /build/buildd/glib2.0-2.39.92/./gio/gdesktopappinfo.c:3363

...meaning that, once indicator-datetime makes the mistake of calling g_app_info_get_all_for_type(), glib will keep polling "/usr/share/ubuntu/applications" and "/usr/local/share/applications" every four seconds forever, even though the app doesn't use that mime information again. :/

Charles Kerr (charlesk) wrote :

With a call to g_app_info_get_all_for_type():

> Wakeups:
> PID Process Wake/Sec Kernel Functions
> 8242 indicator-datetime-s 0.25 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)
> 8237 indicator-datetime-s 0.02 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)
> Total 0.27

Without the call:

> Wakeups:
> PID Process Wake/Sec Kernel Functions
> 16939 indicator-datetime-s 0.02 (schedule_hrtimeout_range_clock, hrtimer_wakeup) (very low)

Charles Kerr (charlesk) on 2014-03-24
Changed in glib2.0 (Ubuntu):
assignee: nobody → Ryan Lortie (desrt)
Charles Kerr (charlesk) wrote :

Adding Ryan for a second opinion since he's got his name as co-Author on gdesktopappinfo.c ;-)

desrt (desrt) wrote :

This is my fault indeed. I introduced the code that added this watch without remembering that it does the wrong thing in the case of missing directories. I think the correct fix here is to reevaluate our approach to dealing with missing files in the inotify monitor...

Charles Kerr (charlesk) on 2014-03-28
Changed in indicator-datetime:
status: Confirmed → In Progress
Changed in indicator-datetime (Ubuntu):
status: New → In Progress
assignee: nobody → Charles Kerr (charlesk)
importance: Undecided → Medium
Changed in glib2.0 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-datetime - 13.10.0+14.04.20140328-0ubuntu1

indicator-datetime (13.10.0+14.04.20140328-0ubuntu1) trusty; urgency=low

  [ Charles Kerr ]
  * Short-term workaround for the GIO GAppInfo wakeup bug discussed in
    bug 1296233 (LP: #1296233)
  * Improved translator comments for better time/date localization. (LP:
 -- Ubuntu daily release <email address hidden> Fri, 28 Mar 2014 16:11:23 +0000

Changed in indicator-datetime (Ubuntu):
status: In Progress → Fix Released
Charles Kerr (charlesk) on 2014-04-08
Changed in indicator-datetime:
status: In Progress → Fix Released
Dmitry Shachnev (mitya57) wrote :

Any update on fixing GIO? Maybe we can already revert this hack?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers