** Also affects: unity8 (Ubuntu RTM)
Importance: Undecided
Status: New
** Changed in: unity8 (Ubuntu)
Assignee: Gerry Boland (gerboland) => Albert Astals Cid (aacid)
** Changed in: unity8 (Ubuntu RTM)
Assignee: (unassigned) => Albert Astals Cid (aacid)
** Changed in: unity8 (Ubuntu RTM)
Importance: Undecided => High
** Changed in: unity8 (Ubuntu)
Status: Triaged => In Progress
** Changed in: unity8 (Ubuntu)
Status: In Progress => Opinion
** Changed in: unity8 (Ubuntu RTM)
Status: New => Opinion
--
You received this bug notification because you are a member of Desktop
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 “qtbase-opensource-src” package in Ubuntu:
New
Status in “unity8” package in Ubuntu:
Opinion
Status in “unity8” package in Ubuntu RTM:
Opinion
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
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
