GNOME Bugzilla – Bug 759980
Crash/Unresponsive when gear / settings button is pressed
Last modified: 2016-05-18 14:40:25 UTC
When the cog (settings) button is pressed, Geary becomes unresponsive. Shortly after Geary crashes. Behaviour started after the latest update to qt5-base 5.5.1-7. This is observed on Arch Linux x64 with latest Geary.
To correct my previous statement. This seems to be unrelated to qt5 at all. Furthermore, after pressing the cog button, the whole of GNOME is affected. Clicks, button presses and Super, do not work until Geary crashes and stops hogging the resources.
I can confirm this bug, it is *very* annoying. After pressing the cog button the menu shows up, but after a second the entire system hangs. Furthermore, if I press CRTL+E instead to bring up the preferences window, nothing seems to happen. I don't know whether this is directly related, but I use Geary 0.10.0 on Ubuntu GNOME 15.10 amd64 (GNOME 3.18) in VirtualBox 5.0.10.
By the way, I had my GNOME Shell top bar application menu disabled. When I enable the top bar application menu, there is no cog menu and everything works just fine, including the CRTL+E shortcut!
Hi there, thanks for reporting the problem. Is it still an issue for you? If so, can you obtain a backtrace of the crash and attach it to this bug? Follow the steps to produce geary.gdb as outlined here https://wiki.gnome.org/Apps/Geary/FAQ if you are unsure how to do that.
I tried to produce a crash log, but I couldn't. It turns out Geary spawns a thread as soon as the cog is pressed and this thread for some reason overwhelms the system. By repeatedly clicking on the cog itself again, the thread finally crashes and the system recovers, but the cog menu needs to be opened again. This invoked the same buggy thread and the whole thing repeats. I tried to record this with Gnome's built-in screen recorder, but as soon as I click the cog the recorder gets killed. I guess this is because of insufficient system resources left for the recording. At least that what I thought until I tried a whole lot of other screen recorders, none of which were able to record Geary. Don't get me wrong, they worked fine, but for some reason Gears was the only windows that was not recorded as if it wasn't there. This is something I don't even know how to explain. I am going to film it with my camera later to show exactly what I mean. On top of that I tried debugging Geary with Valgrind as well, but for some reason it seems incompatible and doesn't work. I'll be back with more info later. I encourage everyone to try this for themselves as it is very strange behaviour.
(In reply to Kaaiman from comment #3) > By the way, I had my GNOME Shell top bar application menu disabled. > > When I enable the top bar application menu, there is no cog menu and > everything works just fine, including the CRTL+E shortcut! Hi Kaaiman, how did you disabled the GNOME Shell top bar application menu? I just installed Ubuntu GNOME 15.10 amd64 in a VM and the application menu is obviously there still. Are you running this in GNOME classic?
(In reply to kgizdov from comment #0) > When the cog (settings) button is pressed, Geary becomes unresponsive. > Shortly after Geary crashes. Behaviour started after the latest update to > qt5-base 5.5.1-7. > > This is observed on Arch Linux x64 with latest Geary. Hi kgizdov, I just installed latest Arch Linux x64 and Geary 0.10 in a VM, and do not get a cog menu appearing at all. What version of Geary do you have installed and which desktop envrionment are you using?
Hi Micheal, I'm not sure if you are familiar with this, but GNOME allows you to have the application of the currently viewed app either in your task bar (usually at the top of the screen) or in the title bar of the app window itself. By default, I guess, GNOME puts the application menu in the task bar. You can change that using a `gsettings` command or simply by using GNOME Tweak Tool, which is a much easier to use UI to gsettings. In my previous post, I promised that I will debug more, but then it was pointed out to me that GNOME Geary is dead. So I didin't bother. Is that really the case or not? Information seems to be flaky at best for this. If you still need me to debug more, I can try later this week. Thank you.
(In reply to kgizdov from comment #8) > > I'm not sure if you are familiar with this, but GNOME allows you to have the > application of the currently viewed app either in your task bar (usually at > the top of the screen) or in the title bar of the app window itself. By > default, I guess, GNOME puts the application menu in the task bar. You can > change that using a `gsettings` command or simply by using GNOME Tweak Tool, > which is a much easier to use UI to gsettings. Oh okay, I didn't know that - but does this bug not relate to the cog menu, which usually appears on the right hand side of the menu? I.e. not the application menu? I just disabled the application menu in the top bar using Tweak, and it appeared on the left hand side of Geary's header bar, but when I clicked it I didn't get any crash or unresponsiveness. > In my previous post, I promised that I will debug more, but then it was > pointed out to me that GNOME Geary is dead. So I didin't bother. Is that > really the case or not? Information seems to be flaky at best for this. Yes, Geary back in action after a bit of a hiatus. So if you could debug this a bit further and post your results here, that would be great. Thanks!
Ah, so I can get the gear menu appearing now - Geary needs to be launched with the setting disabling the top bar already set for it to appear. Also, can now reproduce with the Arch VM. It seems like there's some interaction occurring between gnome-shell and Geary when unresponsive - both are running at 100% cpu. It start on mouse down over the gear button, and the popup never appears. Maybe some GMenu/GtkApplication/DBus interaction? Will need to be able to SSH into the VM to debug it more, because gnome-shell isn't responsive when this is happening. App menu shortcuts not working when using the gear menu is active is a separate issue: Bug 747179
Created attachment 326907 [details] [review] Fix app & desktop becoming unresponsive when clicking the gear menu When the shell is not showing the app menu, we are adding a gear menu and using that for the app menu to work around an issue in Mint Cinnamon always showing a menu bar when an app menu was present. However under gnome-shell, this causes both Geary and gnome-shell to both start fully consuming the CPU when the gear menu was activated. Perhaps GtkApplication{Window} was notifying or querying shell about the state of the actions since they are in the in the "app" namespace, but shell not knowing or caring about them was returning an error, causing Geary to retry? Removing the gear menu and letting GTK+ add its own app menu to the header when shell is not showing it fixes the issue. We could load the app_menu actions into the "win" namespace, but that would require adding yet more workarounds (at least a duplicate app_menu.ui file or something else similary sucky) for someone else's bug and for users that will never see or need the fix.
The original comment said "Unfortunately Mint (Cinnamon, I believe) and maybe others" and was rather correct - Ubuntu GNOME Trusty also inserts a menu bar. Since 0.11 is still going to support GTK+ 3.10 and that is the version Trusty ships with, I'm going to re-target this for 0.12. We'll end support for GTK+ 3.10 then, and so GNOME Trusty users will either need to upgrade GTK (which should hopefully fix their menu bar issue) or stick with 0.11.
In the mean time, if you build Geary with the above patch applied, or build it from "the bug/759980-unresponsive-gear-menu" branch from my GitHub repo <https://github.com/mjog/geary>, then this bug should be fixed.
*** Bug 766534 has been marked as a duplicate of this bug. ***
Created attachment 328035 [details] Unnecessary bar with patch applied After applying the patch like you instructed, I am left with a menu bar containing a single option. I don't think that this was intended
(In reply to Britt Yazel from comment #15) > Created attachment 328035 [details] > Unnecessary bar with patch applied > > After applying the patch like you instructed, I am left with a menu bar > containing a single option. I don't think that this was intended Hmm, yeah that's not right. Okay, so can you let me know the following: * What version of GTK+ 3 do you have installed? * What is your desktop environment and window manager (and their versions)? * The output of running `gsettings get org.gnome.settings-daemon.plugins.xsettings overrides`? Thanks.
GTK+ 3.20.4 Desktop environment is Gnome 3.20.2, and the window manager is Mutter 3.20.2 The output is: {'Gdk/WindowScalingFactor': <1>, 'Gtk/ShellShowsAppMenu': <0>} Other notes: when I enable the application menu the icon menu in the upper left AND the menu bar both disappear. Also, right after upgrading to Gnome 3.20, Gedit and Builder had this same issue, and it was fixed in the following point releases. This is probably a change that happened with 3.20
Great, thanks. I will look into this. One last thing, if you have the GTK+ Inspector installed (https://wiki.gnome.org/Projects/GTK+/Inspector), run it for Geary and let me know the value of: - GtkSettings `gtk-shell-shows-app-menu` and `gtk-shell-shows-menu-bar` properties - MainWindow `show-menubar` property (Select the desired object in the All Objects hierarchy, click Show Details on the toolbar, select Properties from the dropdown, then find the property in the table). Ta!
gtk-shell-shows-app-menu FALSE gtk-shell-shows-menubar FALSE MainWindow > show-menubar TRUE
Review of attachment 326907 [details] [review]: Menubar reappearing with GTK 3.20. Investigate further.
Created attachment 328082 [details] [review] Refreshed patch, also disables main-window's menubar.
(In reply to Britt Yazel from comment #15) > > After applying the patch like you instructed, I am left with a menu bar > containing a single option. I don't think that this was intended Hi Britt, can you try the refreshed patch and let me know if it both fixes the problem and ensures no empty menu bar is shown?
Sure, do I need both patches or does this supercede the other?
Ok, I applied the patch and it seems to work just fine. That menu bar is now hidden.
The attached patch has been committed to master, and will be in 0.12 when it is released. If you need a fix for this issue before them, apply the patch to the 0.11 source and rebuild and you should be fine.