touch-packages team mailing list archive

[Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>]

** Changed in: unity8 (Ubuntu)
     Assignee: Michał Sawicz (saviq) => Gerry Boland (gerboland)

** Changed in: unity8 (Ubuntu)
       Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1384776

Title:
  Occasional hang in unity 8 dash on the phone

Status in “network-manager” package in Ubuntu:
  In Progress
Status in “unity8” package in Ubuntu:
  Triaged

Bug description:
  The dash is sometimes hanging on the phone.

  See the attached backtrace.

  The issue is as follows: we are maintaining a client-side tree of all
  NetworkManager devices.  When we see that a new device has been added,
  we query its properties in order to build our local proxy.  Doing this
  means that we are making QtDBus calls from a signal handler.  Due to a
  bug in QtDBus this is not safe.

  libdbus-1 has a recursive lock on its DBusConnection.  When the signal
  arrives, the lock is acquired and the sginal handler is run.  The
  signal handler can make DBus calls (which also require the lock)
  because the lock is recursive.  QtDBus also has a lock that is always
  acquired before the libdbus-1 connection lock is acquired.

  Unfortuntaely, the QtDBus lock is not acquired in the case of the
  incoming call from DBus -- only the DBus lock is.

  
  If another thread tries to do an unrelated DBus call meanwhile, it will acquire the QtDBus lock first and then the DBus lock (which is held because of the signal that arrived).  Once the signal handler gets to the point of wanting to make a DBus call (in order to query the properties of the just-added network device) it will attempt to acquire the QtDBus lock.  This is a lock-inversion deadlock.

  There are at least three bugs here:

  1) QtDBus should be fixed in order to avoid this sort of lock
  inversion problem.  Even if we fix this one situation, it seems quite
  likely that issues like this will arise again.

  2) QNetworkManager should avoid the issue in QtDBus until such a time
  as it is fixed.  This could be done by dispatching to a worker thread
  on receipt of signals so that the queries are done in a fresh call
  stack (without the libdbus-1 lock held).

  3) Apparently the only reason we are using NetworkManager at all is in
  order to know if we are on a 3G connection or not (in order to avoid
  too much data charges).  This would be much easier to do if
  NetworkManager provided a property that we could watch directly
  instead of bringing up an entire tree of objects in order to answer a
  very simple question.  To that end I've filed
  https://bugzilla.gnome.org/show_bug.cgi?id=739080 which we can
  hopefully get addressed relatively quickly.

  
  I consider 3) to be the real fix as far as we are concerned, but we should probably ensure that the Qt people know about 1) and 2).  Either of those could function as a workaround for us in the meantime, but the idea that we are creating this complex object tree to answer a simple question is ridiculous, so we should really fix that directly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1384776/+subscriptions