[Touch-packages] [Bug 1625235] [NEW] lxc doesn't follow xdg basedir spec if XDG_DATA_HOME is set
Public bug reported: Pretty simple bug: lxc-create: utils.c: mkdir_p: 253 Permission denied - failed to create directory '/home/desrt/.local/share/lxc' desrt@humber:~$ echo $XDG_DATA_HOME /home/desrt/.var/lib lxc has no business putting files in ~/.local/share if XDG_DATA_HOME is set elsewhere. Please see https://standards.freedesktop.org/basedir- spec/basedir-spec-latest.html ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Description changed: Pretty simple bug: lxc-create: utils.c: mkdir_p: 253 Permission denied - failed to create directory '/home/desrt/.local/share/lxc' - desrt@humber:~/code/dconf$ echo $XDG_DATA_HOME + desrt@humber:~$ echo $XDG_DATA_HOME /home/desrt/.var/lib - - lxc has no business putting files in ~/.local/share if XDG_DATA_HOME is set elsewhere. Please see https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html + lxc has no business putting files in ~/.local/share if XDG_DATA_HOME is + set elsewhere. Please see https://standards.freedesktop.org/basedir- + spec/basedir-spec-latest.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1625235 Title: lxc doesn't follow xdg basedir spec if XDG_DATA_HOME is set Status in lxc package in Ubuntu: New Bug description: Pretty simple bug: lxc-create: utils.c: mkdir_p: 253 Permission denied - failed to create directory '/home/desrt/.local/share/lxc' desrt@humber:~$ echo $XDG_DATA_HOME /home/desrt/.var/lib lxc has no business putting files in ~/.local/share if XDG_DATA_HOME is set elsewhere. Please see https://standards.freedesktop.org /basedir-spec/basedir-spec-latest.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1625235/+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 1506744] Re: Newly installed applications do not show in the dash
The latest patch looks good to me, but with a couple of notes (no need to fix these): - using the _full() version of the timeout call is not necessary here - now that this patch is simplified it becomes easy to see how all of this is just putting values into one structure and then later moving them into another structure. It seems like we could have just used the first structure type, or even just fixed the other queue mechanism to add the delay. Oh well. No real gain from making that change at this point. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libunity in Ubuntu. https://bugs.launchpad.net/bugs/1506744 Title: Newly installed applications do not show in the dash Status in GLib: Confirmed Status in gnome-menus package in Ubuntu: In Progress Status in libunity package in Ubuntu: Fix Released Status in unity package in Ubuntu: Invalid Bug description: I am running 15.10 development version fully up to date, I installed it a few days ago and I have an issue with newly installed applications not appearing in the dash when I search for them, they can be started via console but the icons/launchers of newly installed applications will only appear in the dash after session is restarted. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: unity 7.3.2+15.10.20151002.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CurrentDesktop: Unity Date: Fri Oct 16 08:41:39 2015 InstallationDate: Installed on 2015-10-11 (4 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20151011) SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/1506744/+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 1506744] Re: Newly installed applications do not show in the dash
To elaborate on the previous remark: why didn't we just replace: menu_monitor_queue_event (event_info); with: g_timeout_add_seconds (2, menu_monitor_queue_event, event_info); (and make sure menu_monitor_queue_event() returns FALSE)? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libunity in Ubuntu. https://bugs.launchpad.net/bugs/1506744 Title: Newly installed applications do not show in the dash Status in GLib: Confirmed Status in gnome-menus package in Ubuntu: In Progress Status in libunity package in Ubuntu: Fix Released Status in unity package in Ubuntu: Invalid Bug description: I am running 15.10 development version fully up to date, I installed it a few days ago and I have an issue with newly installed applications not appearing in the dash when I search for them, they can be started via console but the icons/launchers of newly installed applications will only appear in the dash after session is restarted. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: unity 7.3.2+15.10.20151002.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CurrentDesktop: Unity Date: Fri Oct 16 08:41:39 2015 InstallationDate: Installed on 2015-10-11 (4 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20151011) SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/1506744/+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 1506744] Re: Newly installed applications do not show in the dash
The patch in comment 42 is not acceptable, for two big reasons. First: you need to hold a ref on the GFile object when you put it into the info struct. This means that you cannot simply use g_free for the struct: you need to write a custom free func that handles the unref as well. Also: you can't cast g_source_remove() to a GDestroyNotify and expect that to work... one takes a pointer, and the other an int. This may randomly work on some architectures, sometimes, but you cannot rely on this. The entire act of keeping the list is slightly suspect. At the sprint I think I mentioned that it would be better to have one global timeout that is set (and reset) when any activity happens. The timeout would run after the activity died down, and it would handle all things together in one go. In that case, you'd still need a list, except for the info objects themselves. It's also fine to keep the list of the timeout IDs, but you can't free it in the way that you're doing in the current patch. Another nice approach, if you want to avoid running the callbacks after teardown: store a weak pointer to the main object in each of the info structs (g_object_add_weak_pointer). The info structs are then used as the user_data to the timeout (this assumes you keep the multiple timeouts). If you find the weak pointer to be empty, then just return without doing anything. That also means that you don't need to handle the "cleanup" -- it will happen automatically. It also means that you can avoid the custom free function if you are clever: the timeout will always run once, and you can do the cleanup from the normal handler (taking care regarding the early exit discussed above). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libunity in Ubuntu. https://bugs.launchpad.net/bugs/1506744 Title: Newly installed applications do not show in the dash Status in GLib: Confirmed Status in gnome-menus package in Ubuntu: In Progress Status in libunity package in Ubuntu: Fix Released Status in unity package in Ubuntu: Invalid Bug description: I am running 15.10 development version fully up to date, I installed it a few days ago and I have an issue with newly installed applications not appearing in the dash when I search for them, they can be started via console but the icons/launchers of newly installed applications will only appear in the dash after session is restarted. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: unity 7.3.2+15.10.20151002.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu2 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CurrentDesktop: Unity Date: Fri Oct 16 08:41:39 2015 InstallationDate: Installed on 2015-10-11 (4 days ago) InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20151011) SourcePackage: unity UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/1506744/+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 1512002] Re: Annoying dialog "Authentication is required to change your own user data"
Although I agree that it makes sense to allow the user to modify their own data even if not "actively logged in", I think it would also be interesting to track down the program that is the real source of this problem. ie: let's figure out which part of the session is writing to accountsservice at random times... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1512002 Title: Annoying dialog "Authentication is required to change your own user data" Status in accountsservice: Confirmed Status in accountsservice package in Ubuntu: Confirmed Status in indicator-messages package in Ubuntu: Confirmed Status in policykit-1-gnome package in Ubuntu: Confirmed Bug description: Every few days a dialog pops up saying "Authentication is required to change your own user data" with an entry field for a password. If I type my user's password the dialog will reappear with an empty entry field. If I click on the cross to close the window many times it will be gone, but reappear a few days later. I don't know what this window is for and it makes no difference whether I close it or leave it. I don't use the gnome keyring. This started with Ubuntu 15.04 or maybe with an earlier release, and is still there in Ubuntu 15.10, also on machines I did a fresh install. To manage notifications about this bug go to: https://bugs.launchpad.net/accountsservice/+bug/1512002/+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 1485659] Re: Date/time indicator doesn't update after changing time zone
A couple of notes: - this is fixed upstream in GLib already - watching dbus for the signal is fine, but you should not use dbus to read the property in the first place. This will result in activation of the datetime service, which is expensive. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-datetime in Ubuntu. https://bugs.launchpad.net/bugs/1485659 Title: Date/time indicator doesn't update after changing time zone Status in indicator-datetime package in Ubuntu: In Progress Bug description: After changing the timezone the time displayed in the date/time indicator is still in my old time zone. I sent a signal to the indicator-datetime-service process, and after it restarted the correct time was displayed. ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: indicator-datetime 13.10.0+15.10.20150728-0ubuntu2~gcc5.1 ProcVersionSignature: Ubuntu 4.1.0-3.3-generic 4.1.3 Uname: Linux 4.1.0-3-generic x86_64 ApportVersion: 2.18-0ubuntu6 Architecture: amd64 CurrentDesktop: Unity Date: Mon Aug 17 08:51:44 2015 EcryptfsInUse: Yes InstallationDate: Installed on 2015-02-19 (178 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20150110) SourcePackage: indicator-datetime UpgradeStatus: Upgraded to wily on 2015-07-01 (46 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1485659/+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 1315434] Re: Mouse with no time remaining estimate showing in preference to battery being charged
Just to play devil's advocate a bit here: The logic taken in this bug (that we should show the device that will run out of power first) seems perfectly sound, but it makes a very large assumption, which I suspect will often be untrue: that reporting of time remaining on mice will always be completely accurate. I think there are two problems with the assumption. The first is that there have been reports (one just now on IRC from jcastro) about faulty hardware/driver combos that report things like 1 minute remaining all the time. Users with this hardware would probably like that fixed, but for lack of a fix, would probably prefer to be able to go on with their lives with the minimum amount of disruption. Second issue is that I wonder if estimated time left reporting on a device which has a battery that lasts up to a year is _ever_ accurate to the hours or minutes that we would need it to be in order to meaningfully compare it against laptop battery life. Those two point combined cause me to believe that the only case in which this feature would be engaged would be in the wrong case. Maybe it makes sense to just remove it entirely after all? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-power in Ubuntu. https://bugs.launchpad.net/bugs/1315434 Title: Mouse with no time remaining estimate showing in preference to battery being charged Status in indicator-power package in Ubuntu: In Progress Bug description: When my laptop battery is in a charging state, but is not fully charged, I expect it to be displayed in preference to my mouse, which has no time remaining estimate. The spec here: https://wiki.ubuntu.com/Power says: If anything is discharging, the menu title should represent the component (not battery, but component) that is estimated to lose power first. For example, if your notebook battery is estimated to discharge in 1 hour 47 minutes, and your wireless mouse battery is estimated to discharge in 27 minutes, the menu title should represent the mouse. but there doesn't seem to be any guideline to what happens when a battery is being charged. I suggest the time remaining to charge a battery should be displayed in preference to the power level in a wireless mouse. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: indicator-power 12.10.6+14.04.20140411-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Fri May 2 11:50:36 2014 InstallationDate: Installed on 2013-11-26 (156 days ago) InstallationMedia: Ubuntu 13.10 Saucy Salamander - Release amd64 (20131016.1) SourcePackage: indicator-power UpgradeStatus: Upgraded to trusty on 2014-01-17 (104 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1315434/+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 1430542] [NEW] Indicator doesn't use weighted average with different-sized batteries
Public bug reported: The indicator implements the spec: https://wiki.ubuntu.com/Power#Handling_multiple_batteries which states: Their percentages should be averaged. Apparently this was taken to mean the simple arithmetic mean, and not the weighted average (by the capacity of each battery). http://bazaar.launchpad.net/~indicator-applet-developers/indicator- power/trunk.15.04/view/head:/src/service.c#L1316 shows: const double percent = sum_percent / n_batteries; This means that if one battery is twice as large as another, then after that battery is discharged, 50% would be reported. I'd expect 33%. The spec needs to be updated to be less ambiguous about the intended meaning of the word average and the code needs to be fixed. ** Affects: indicator-power (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-power in Ubuntu. https://bugs.launchpad.net/bugs/1430542 Title: Indicator doesn't use weighted average with different-sized batteries Status in indicator-power package in Ubuntu: New Bug description: The indicator implements the spec: https://wiki.ubuntu.com/Power#Handling_multiple_batteries which states: Their percentages should be averaged. Apparently this was taken to mean the simple arithmetic mean, and not the weighted average (by the capacity of each battery). http://bazaar.launchpad.net/~indicator-applet-developers/indicator- power/trunk.15.04/view/head:/src/service.c#L1316 shows: const double percent = sum_percent / n_batteries; This means that if one battery is twice as large as another, then after that battery is discharged, 50% would be reported. I'd expect 33%. The spec needs to be updated to be less ambiguous about the intended meaning of the word average and the code needs to be fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1430542/+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 1284017] Re: gnome-shell crashed with SIGABRT in g_thread_abort()
In fact, I think this was fixed a year ago already: https://bugzilla.gnome.org/show_bug.cgi?id=724929 Did anyone see this in newer Ubuntu releases (ie: the released version of trusty or later)? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to d-conf in Ubuntu. https://bugs.launchpad.net/bugs/1284017 Title: gnome-shell crashed with SIGABRT in g_thread_abort() Status in A simple key-based configuration system: Unknown Status in d-conf package in Ubuntu: New Bug description: gnome-shell crashed on system restart. ProblemType: Crash DistroRelease: Ubuntu 14.04 Package: gnome-shell 3.10.4-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3 Uname: Linux 3.13.0-11-generic x86_64 ApportVersion: 2.13.2-0ubuntu5 Architecture: amd64 CurrentDesktop: GNOME Date: Mon Feb 24 12:24:40 2014 DisplayManager: gdm ExecutablePath: /usr/bin/gnome-shell GsettingsChanges: InstallationDate: Installed on 2014-02-09 (14 days ago) InstallationMedia: Ubuntu-GNOME 14.04 Trusty Tahr - Alpha amd64 (20140121.1) ProcCmdline: gnome-shell --mode=gdm ProcEnviron: SHELL=/bin/false PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 Signal: 6 SourcePackage: gnome-shell StacktraceTop: ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so Title: gnome-shell crashed with SIGABRT in g_mutex_lock() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dconf/+bug/1284017/+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 1284017] Re: gnome-shell crashed with SIGABRT in g_thread_abort()
It's worth noting that this bug can no longer occur as it is described here -- g_mutex_lock() has been rewritten and the new version doesn't abort. That said, the underlying issue that was causing the misuse of a mutex could very well still exist... Unfortunately, it's very difficult to guess what that may be, at this point. ** Bug watch added: GNOME Bug Tracker #724929 https://bugzilla.gnome.org/show_bug.cgi?id=724929 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to d-conf in Ubuntu. https://bugs.launchpad.net/bugs/1284017 Title: gnome-shell crashed with SIGABRT in g_thread_abort() Status in A simple key-based configuration system: Unknown Status in d-conf package in Ubuntu: New Bug description: gnome-shell crashed on system restart. ProblemType: Crash DistroRelease: Ubuntu 14.04 Package: gnome-shell 3.10.4-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3 Uname: Linux 3.13.0-11-generic x86_64 ApportVersion: 2.13.2-0ubuntu5 Architecture: amd64 CurrentDesktop: GNOME Date: Mon Feb 24 12:24:40 2014 DisplayManager: gdm ExecutablePath: /usr/bin/gnome-shell GsettingsChanges: InstallationDate: Installed on 2014-02-09 (14 days ago) InstallationMedia: Ubuntu-GNOME 14.04 Trusty Tahr - Alpha amd64 (20140121.1) ProcCmdline: gnome-shell --mode=gdm ProcEnviron: SHELL=/bin/false PATH=(custom, no user) XDG_RUNTIME_DIR=set LANG=en_US.UTF-8 Signal: 6 SourcePackage: gnome-shell StacktraceTop: ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 g_mutex_lock () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so ?? () from /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so Title: gnome-shell crashed with SIGABRT in g_mutex_lock() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: To manage notifications about this bug go to: https://bugs.launchpad.net/dconf/+bug/1284017/+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 1364070] Re: vivid, utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher addition through gsettings isn't picked up
Yup. This is a GIO issue. We register a file monitor and don't bother checking if desktop files changed until we see the file monitor has fired. Due to inotify implementation issues, this usually happens about ~1s later. We will need to add a mechanism to force a reload and/or do it automatically in case we see a lookup failure. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/1364070 Title: vivid, utopic and trusty unity (7.3.1+14.10.20140811-0ubuntu1) launcher addition through gsettings isn't picked up Status in The G Library - GLib: Unknown Status in Unity: Invalid Status in unity package in Ubuntu: Invalid Bug description: As discussed on IRC, I tried to change the favorites key, and 3 trials on 10 didn't make any change in what the launcher displays. seb128 reproduced it as well. (just be aware that we just create the .desktop file just before). The exact same code seems to work 100% of the time on trusty. So, we: 1. create the desktop file 2. from gi.repository import GLib, Gio gsettings = Gio.Settings(schema_id=com.canonical.Unity.Launcher, path=/com/canonical/unity/launcher/) then, get the favorites list and add the desktop file. 3. gsettings.set_strv(favorites, new_launcher_list) - No launcher icon added from new launcher list. However, a $ gsettings get shows that desktop file (which is present. Note that changing the list and changing it back works. This was first experimented on June 2014 and reported on IRC. To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/1364070/+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] [NEW] Occasional hang in unity 8 dash on the phone
Public bug reported: 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. ** Affects: unity8 (Ubuntu) Importance: Undecided Status: New -- 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
[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
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 1344386] Re: Do.exe crashed with SIGABRT in __GI_raise()
GLib completely changed the implementation of GMutex from being based on POSIX primatives to being based on a home-grown solution that is substantially faster (and with room for further improvements). This caused deadlocks/crashes in some Vala programs, and I wonder if the same thing is going on with Mono. See this bug: https://bugzilla.gnome.org/show_bug.cgi?id=733500 ** Bug watch added: GNOME Bug Tracker #733500 https://bugzilla.gnome.org/show_bug.cgi?id=733500 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1344386 Title: Do.exe crashed with SIGABRT in __GI_raise() Status in “glib2.0” package in Ubuntu: New Status in “gnome-do” package in Ubuntu: Confirmed Bug description: Do.exe crashed with SIGABRT in __GI_raise() ProblemType: Crash DistroRelease: Ubuntu 14.10 Package: gnome-do 0.9-1build1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 ApportVersion: 2.14.4-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Fri Jul 18 17:47:01 2014 ExecutablePath: /usr/lib/gnome-do/Do.exe InstallationDate: Installed on 2014-05-16 (63 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417) InterpreterPath: /usr/bin/mono-sgen ProcCmdline: /usr/bin/cli /usr/lib/gnome-do/Do.exe Signal: 6 SourcePackage: gnome-do StacktraceTop: __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 __GI_abort () at abort.c:89 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ?? () Title: Do.exe crashed with SIGABRT in __GI_raise() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1344386/+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 1344386] Re: Do.exe crashed with SIGABRT in __GI_raise()
The new mutex implementation detects the (error) case when you try to unlock a mutex that is not locked. Callers are supposed to acquire the Gtk lock before calling gtk_main() and I guess gnome-do isn't doing that... POSIX silently ignores this... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1344386 Title: Do.exe crashed with SIGABRT in __GI_raise() Status in “glib2.0” package in Ubuntu: Invalid Status in “gnome-do” package in Ubuntu: Confirmed Bug description: Do.exe crashed with SIGABRT in __GI_raise() ProblemType: Crash DistroRelease: Ubuntu 14.10 Package: gnome-do 0.9-1build1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 ApportVersion: 2.14.4-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Fri Jul 18 17:47:01 2014 ExecutablePath: /usr/lib/gnome-do/Do.exe InstallationDate: Installed on 2014-05-16 (63 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417) InterpreterPath: /usr/bin/mono-sgen ProcCmdline: /usr/bin/cli /usr/lib/gnome-do/Do.exe Signal: 6 SourcePackage: gnome-do StacktraceTop: __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 __GI_abort () at abort.c:89 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ?? () Title: Do.exe crashed with SIGABRT in __GI_raise() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1344386/+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 1344386] Re: Do.exe crashed with SIGABRT in __GI_raise()
Invalid for glib since the bug is confirmed as being in gnome-do (not acquiring the lock before gtk_main). ** Changed in: glib2.0 (Ubuntu) Status: New = Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1344386 Title: Do.exe crashed with SIGABRT in __GI_raise() Status in “glib2.0” package in Ubuntu: Invalid Status in “gnome-do” package in Ubuntu: Confirmed Bug description: Do.exe crashed with SIGABRT in __GI_raise() ProblemType: Crash DistroRelease: Ubuntu 14.10 Package: gnome-do 0.9-1build1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 ApportVersion: 2.14.4-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Fri Jul 18 17:47:01 2014 ExecutablePath: /usr/lib/gnome-do/Do.exe InstallationDate: Installed on 2014-05-16 (63 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417) InterpreterPath: /usr/bin/mono-sgen ProcCmdline: /usr/bin/cli /usr/lib/gnome-do/Do.exe Signal: 6 SourcePackage: gnome-do StacktraceTop: __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 __GI_abort () at abort.c:89 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ?? () Title: Do.exe crashed with SIGABRT in __GI_raise() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1344386/+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 1344386] Re: Do.exe crashed with SIGABRT in __GI_raise()
** Also affects: do Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to glib2.0 in Ubuntu. https://bugs.launchpad.net/bugs/1344386 Title: Do.exe crashed with SIGABRT in __GI_raise() Status in Do: New Status in “glib2.0” package in Ubuntu: Invalid Status in “gnome-do” package in Ubuntu: Fix Released Bug description: Do.exe crashed with SIGABRT in __GI_raise() ProblemType: Crash DistroRelease: Ubuntu 14.10 Package: gnome-do 0.9-1build1 ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4 Uname: Linux 3.13.0-32-generic x86_64 ApportVersion: 2.14.4-0ubuntu2 Architecture: amd64 CurrentDesktop: GNOME Date: Fri Jul 18 17:47:01 2014 ExecutablePath: /usr/lib/gnome-do/Do.exe InstallationDate: Installed on 2014-05-16 (63 days ago) InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417) InterpreterPath: /usr/bin/mono-sgen ProcCmdline: /usr/bin/cli /usr/lib/gnome-do/Do.exe Signal: 6 SourcePackage: gnome-do StacktraceTop: __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 __GI_abort () at abort.c:89 ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 ?? () Title: Do.exe crashed with SIGABRT in __GI_raise() UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo To manage notifications about this bug go to: https://bugs.launchpad.net/do/+bug/1344386/+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
