[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Changed in: unity8 (Ubuntu) Status: Opinion = In Progress ** Changed in: unity8 (Ubuntu RTM) Status: Opinion = New ** Changed in: unity8 (Ubuntu RTM) Assignee: Albert Astals Cid (aacid) = (unassigned) -- 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: Fix Released Status in qtbase-opensource-src package in Ubuntu: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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-jyri...@ubuntu.com Thu, 27 Nov 2014 13:11:36 + ** Changed in: qtbase-opensource-src (Ubuntu) Status: In Progress = Fix Released -- 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: 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Changed in: unity8 (Ubuntu) Status: In Progress = Invalid ** Changed in: unity8 (Ubuntu RTM) Status: New = Invalid ** Changed in: unity8 (Ubuntu) Assignee: Albert Astals Cid (aacid) = (unassigned) -- 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: Fix Released Status in qtbase-opensource-src package in Ubuntu: Fix Released Status in unity8 package in Ubuntu: Invalid Status in unity8 package in Ubuntu RTM: Invalid 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Reopening, there was just a changelog error in the recent upload. The DBus patches brought unity8 restarts with them, so they couldn't be included in the uploaded. It would need more work apparently than just including those three patches. ** Changed in: qtbase-opensource-src (Ubuntu) Status: Fix Released = Incomplete -- 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: Fix Released Status in “qtbase-opensource-src” package in Ubuntu: Incomplete 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [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- 4ubuntu5 --- qtbase-opensource-src (5.3.2+dfsg-4ubuntu5) vivid; urgency=medium * Rename qt5-qmake-cross-armhf to qt5-qmake-arm-linux-gnueabihf -- Zoltan Balogh zol...@bakter.hu Thu, 20 Nov 2014 10:33:16 + ** Changed in: qtbase-opensource-src (Ubuntu) Status: Incomplete = Fix Released -- 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: Fix Released Status in “qtbase-opensource-src” package in Ubuntu: Incomplete 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Please give ppa:ci-train-ppa-service/landing-027 (package versions 5.3.2 +dfsg-4ubuntu4 ) a try on top of vivid and report back so that I can proceed on validating/testing the landing otherwise. ** Changed in: qtbase-opensource-src (Ubuntu) Status: In Progress = Incomplete -- 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: Fix Released Status in “qtbase-opensource-src” package in Ubuntu: Incomplete 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Changed in: qtbase-opensource-src (Ubuntu) Status: New = In Progress -- 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: Fix Released Status in “qtbase-opensource-src” package in Ubuntu: In Progress 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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** 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 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 “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/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
The patches have been merged upstream. Timo can you have a look at merging them in our packages? ** Also affects: qtbase-opensource-src (Ubuntu) Importance: Undecided Status: New ** Changed in: qtbase-opensource-src (Ubuntu) Assignee: (unassigned) = Timo Jyrinki (timo-jyrinki) ** Changed in: qtbase-opensource-src (Ubuntu) Importance: Undecided = High -- 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 “qtbase-opensource-src” package in Ubuntu: New 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Ryan do you think can try to review https://codereview.qt- project.org/#/c/98353/ https://codereview.qt-project.org/#/c/98354/ https://codereview.qt-project.org/#/c/98355/ ? I've had a look and from my i know nothing about dbus they look fine. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
I'm not sure it would be very helpful for me to review this either -- I'm very unfamiliar with the codebase and even with how locking works in libdbus-1. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Ryan, upstream has questions on https://bugreports.qt- project.org/browse/QTBUG-42189 please can you answer them there? -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Branch linked: lp:~aacid/unity8/networkingstatus -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Tags added: touch-2014-10-30 -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Branch linked: lp:~phablet-team/network-manager/rtm -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
I opened an upstream Qt bug about the dbus issue at https://bugreports .qt-project.org/browse/QTBUG-42189 -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Saviq, Gerry, do you guys think we could try using ubuntu::connectivity::NetworkingStatus in src/CachingNetworkManagerFactory.cpp ? -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Attachment added: backtrace https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1384776/+attachment/4242439/+files/backtrace -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1384776 Title: Occasional hang in unity 8 dash on the phone Status in “unity8” package in Ubuntu: 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/unity8/+bug/1384776/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
Added a network-manager task, as we need it to export a PrimaryConnectionType property which unity8 could then use... ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Changed in: network-manager (Ubuntu) Status: New = In Progress ** Changed in: network-manager (Ubuntu) Importance: Undecided = High ** Changed in: network-manager (Ubuntu) Assignee: (unassigned) = Ryan Lortie (desrt) -- 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: 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Branch linked: lp:~mathieu-tl/network- manager/powersave+primaryconnectiontype -- 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: 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** Tags added: rtm14 ** Changed in: unity8 (Ubuntu) Importance: Undecided = High ** Changed in: unity8 (Ubuntu) Assignee: (unassigned) = Michał Sawicz (saviq) -- 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: 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
** 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
The patch already went upstream in NetworkManager and now we have an Ubuntu package landing soon. The upshot is that we now have a simple DBus property: system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.PrimaryConnectionType which is a string like '802-11-wireless' or 'bluetooth'. If there is no connection then it is an empty string. We don't have normal D-Bus property change notification here but rather a custom-rolled signal from NetworkManager itself (PropertiesChanged). -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
@mathieu - I've just duped #1381500, which we saw in the dogfooding of krillin often enough not to reject as a one-off. Do its logs match the data above? I took a quick look, and couldn't find data I could directly compare. I don't know what I'm looking for though. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
I would like to find who is creating those dbus connections to networkmanager. There are two candidates: a) QNetworkConfigurationManager used in src/CachingNetworkManagerFactory.cpp b) NetworkingStatus.limitedBandwith used in plugins/Dash/CardCreator.js If it is only a) and not b) we should switch src/CachingNetworkManagerFactory.cpp use over to ubuntu::connectivity::NetworkingStatus that also has the hability to provide wheter if we are online or not Of course the original Qt bug should be still fixed so that other people don't step on that problem. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1384776] Re: Occasional hang in unity 8 dash on the phone
QNAM uses QtBearer, which means those are handled by the NetworkManager backend, which I am currently trying to fix up. There are two ways of diserning online status with QtNetwork. 1) QNetworkConfigurationManager has isOnline() method, this can be done on the defaultConfiguration(). 2) QNetworkConfigurationManager has allConfigurations which can take an argument of QNetworkConfiguration::Active which will give a list of all active (online) configurations. Both of which are a bit heavy if only being used for discovering online status. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
