desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #85122
[Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
This bug was fixed in the package qtbase-opensource-src - 5.3.2+dfsg-
4ubuntu8
---------------
qtbase-opensource-src (5.3.2+dfsg-4ubuntu8) vivid; urgency=medium
* Pick up one more DBus fix (LP: #1384776):
- debian/patches/Break-after-handling-the-read-write.patch
qtbase-opensource-src (5.3.2+dfsg-4ubuntu7) vivid; urgency=medium
* Pick up upstream 5.3 branch DBus fixes (LP: #1384776)
- debian/patches/Always-lock-the-DBus-dispatcher-before-dbus_connecti.patch
- debian/patches/Partially-revert-Fix-a-deadlock-introduced-by-the-ra.patch
- debian/patches/QDBusConnection-Merge-the-dispatch-and-the-watch-and.patch
-- Timo Jyrinki <timo-jyrinki@xxxxxxxxxx> Thu, 27 Nov 2014 13:11:36 +0000
** Changed in: qtbase-opensource-src (Ubuntu)
Status: In Progress => Fix Released
--
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:
Fix Released
Status in qtbase-opensource-src package in Ubuntu:
Fix Released
Status in unity8 package in Ubuntu:
In Progress
Status in unity8 package in Ubuntu RTM:
New
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