desktop-packages team mailing list archive

[Launchpad Bug Tracker <1443178@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package accountsservice - 0.6.35-0ubuntu7.2

---------------
accountsservice (0.6.35-0ubuntu7.2) trusty-proposed; urgency=medium

  * debian/patches/0010-set-language.patch:
    Use static variables inside user_get_fallback_value() to prevent
    execution of expensive code at each invocation (LP: #1443178).

 -- Gunnar Hjalmarsson <gunnarhj@xxxxxxxxxx>  Tue, 12 May 2015 18:30:00
+0200

** Changed in: accountsservice (Ubuntu Trusty)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to accountsservice in Ubuntu.
https://bugs.launchpad.net/bugs/1443178

Title:
  Accounts Service always relies on language fallback if never set by
  the user

Status in the base for Ubuntu mobile products:
  New
Status in accountsservice package in Ubuntu:
  Fix Released
Status in accountsservice source package in Trusty:
  Fix Released
Status in accountsservice source package in Vivid:
  Fix Released

Bug description:
  trusty and vivid SRU requests
  =============================

  [Impact]

  Until a user has set the language or regional formats explicitly,
  accountsservice makes the system default values available. The code
  for 'calculating' the system defaults is expensive, and it's triggered
  frequently. The case in the original description of this bug report is
  one example of bad performance for this reason. Another example is a
  system with many users (see e.g. bug #1350393).

  This upload adds a couple of static variables inside the function in
  question, to avoid that the expensive code is executed at each
  invocation. Under certain conditions this improves the performance
  significantly.

  [Test Case]

  Hmm.. There is no easy use case to reproduce the bug. The original
  description below gives a hint.

  [Regression Potential]

  On a multi-user system, if the system defaults in /etc/default/locale
  are changed, accountsservice will keep providing the old system
  default values until the system is rebooted. (Previously it took
  effect instantly.) I think the advantages with the proposed change
  outweigh this subtle change in behavior (which hardly anyone will
  notice anyway).

  Can't think of anything besides that.

  [Original description]

  current build number: 169
  device name: mako
  channel: ubuntu-touch/devel-proposed
  alias: ubuntu-touch/vivid-proposed
  last update: 2015-04-12 20:38:14
  version version: 169
  version ubuntu: 20150412
  version device: 20150210
  version custom: 20150412

  This causes a bad side effect when changing volume via indicator-
  sound, as that will cause a sync to accountsservice in order to sync
  the volume. Once that sync happens, it will request the user
  properties, and in case the user doesn't have a valid language at
  /var/lib/AccountsService/users/<user>, it will always rely on the
  fallback, which would be fine if calculating the fallback wasn't 't so
  cpu or i/o intensive (and that happens multiple times).

  As a test, just flash latest vivid image on mako, don't set any
  language when the wizard shows up, run top and then change the volume
  by pressing volume up/down. This is what I see with mako:

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  2609 phablet   20   0  499660 121220  52688 S   7.6  6.5   0:41.69 unity8
  5600 phablet   20   0    3676   1760   1288 R   6.0  0.1   0:00.19 language-option
  1312 root      20   0  211532  15572  11344 S   1.9  0.8   0:07.25 unity-system-co
  1316 phablet   20   0   36532   3792   2928 S   1.3  0.2   0:01.66 accounts-daemon

  And the reason why:
  src/user.c
  ...
  static void
  user_get_property (GObject    *object,
                     guint       param_id,
                     GValue     *value,
                     GParamSpec *pspec)
  {
          User *user = USER (object);
  ...
          case PROP_LANGUAGE:
                  if (user->language)
                          g_value_set_string (value, user->language);
                  else
                          g_value_set_string (value, user_get_fallback_value (user, "Language"));
                  break;
          case PROP_FORMATS_LOCALE:
                  if (user->formats_locale)
                          g_value_set_string (value, user->formats_locale);
                  else
                          g_value_set_string (value, user_get_fallback_value (user, "FormatsLocale"));
                  break;

  user_set_property never gets called unless the user changes the system
  language from system-settings or wizard.

  Once you change the language, it will set a valid language at
  /var/lib/AccountsService/users/<user>, causing this behavior to stop.

  Another bad side effect of this issue is that it takes quite a while
  for accountsservice to reply back to indicator-sound when the sync
  happens, possibly causing sync aborts (as indicator-sound only waits 1
  second before triggering another sync).

  Some possible ways to fix this issue:
  1) Make wizard to set language even when the selected language is already the default one;
  2) Change accountsservice to save the fallback value at the first time it gets that from the system;

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1443178/+subscriptions