Description of problem: Affected systems are two x86_64 Cauldron VMs (VirtualBox) fully updated. The problem probably appeared on or around the week before Christmas. It took a while to discover that the icon I was clicking belonged to mgaonline. No error messages of any type are generated anywhere I know to look. The only way I know to "fix" a partially locked-up system is to use VirtualBox's "send ACPI shutdown signal" option to kill it and re-start. I have been updating these systems manually since the problem first cropped up as I knew a lot of work had already been done and was continuing to be done to fix up execution of applications with elevated privileges in LXDE and Mate and some other "light" desktops. The affected systems are both LXDE-only and worked perfectly before late December when certain fixes to polkit and gksu started to appear. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Boot to desktop 2.Wait for updates to be notified by red exclamation mark icon in system tray 3.Observe that left-clicking the icon produces no discernible effect. 4.Observe that right-clicking said icon renders the rest of the desktop unresponsive Reproducible: Steps to Reproduce:
Sorry, got src rpm from wrong place. Should be mgaonline-3.5-1.mga4.src.rpm Also known to be a problem with 3.2-1.mga4 and 3.3-1.mga4
Source RPM: mgaonline-2.81-1.mga3.src.rpm (just guessing really) => mgaonline-3.5-1.mga4.src.rpm (just guessing really)
Are you sure you have the latest version? What's the output of this command: rpm -qa|grep mgaonline
Keywords: (none) => NEEDINFOCC: (none) => mageia
Just checked both systems again. Output is: [root@Cauldron4B2 ~]# rpm -qa|grep mgaonline mgaonline-3.5-1.mga4 and [root@Cauldron4B1 ~]# rpm -qa|grep mgaonline mgaonline-3.5-1.mga4 see also comment 1
CC: (none) => thierry.vignaud
This is a gtk2 -> gtk3 regression
CC: (none) => olavSource RPM: mgaonline-3.5-1.mga4.src.rpm (just guessing really) => gtk+3.0, mgaonline-3.5-1.mga4.src.rpm
Created attachment 4806 [details] mgaapplet log when the StatusIcon receives the 'popup_menu' signal, it calls popup_for_device() on the menu. _If_ the notification was not manually closed, gtk3 fails.
Created attachment 4807 [details] GDB trace Here's the call trace that leads to previous logs. Note that one can run 'killall mgapplet' on any tty or ssh session in order to unfreeze X11
Blocks: (none) => 11778
commit 4b2d6e63c5b60495fe47e7de6e998cfa060614bc Author: Thierry Vignaud <thierry.vignaud@...> Date: Fri Jan 17 07:36:18 2014 +0100 workaround X11 hanging (mga#12280) Since commit 95b9cd06f14a9817090584d72830df870c591acc, we run a gtk main loop after displaying a notification, else actions when clickong notification buttons are ignored by gtk+/libnotify However, if the notification is not manually closed, we never exit this main loop. In that case, gtk+ fails with: (mgaapplet:9060): Gtk-CRITICAL **: gtk_window_set_accept_focus: assertion 'GTK_IS_WINDOW (window)' failed from: data=<optimized out>, destroy=0x0, button=3, activate_time=5407876) at gtkmenu.c:1613 And X11 is stuck. As a workaround, since libnotify offers no way to be notified when notification is automatically closed, just add a timeout for exiting the main loop. At worse, X11 will be stuch only 5 seconds. --- Commit Link: http://gitweb.mageia.org/software/mgaonline/commit/?id=4b2d6e63c5b60495fe47e7de6e998cfa060614bc
Olav, any idea on a better solution?
I had to wait a while after the update to mgaonline for more updates on which to test the functionality, but I can declare myself completely happy with the results. Not only do various kinds of clicks on the icon produce the desired outcomes, but I am also getting popup notifications! I'd forgotten about those; it's been a while since I last saw them in LXDE on Cauldron (were they ever there?) and it's a bit of a mixed blessing as I didn't really mourn their passing, but they are back, so I am sure somebody will be glad, if only the debugger who fixed it all:-) So, to quote a thousand others; "Works for me!". Richard
(In reply to Thierry Vignaud from comment #8) > Olav, any idea on a better solution? I'm thinking about: - creating _one_ hidden notification before entering the main loop - never destroy it, but use >close + >clear_actions() then ->update() prior calling >show() when one need to show a notification again
Thierry, if you can still see something wrong in the operation of mgaonline in contexts OTHER THAN where LXDE is the sole desktop environment, then it is probably a different bug. The recent batch or two of upgrades has completely fixed the problem on the two systems for which it was reported. Richard
Status: NEW => RESOLVEDResolution: (none) => FIXED
commit 87813dd7cfa302347b06cd9b0675d18577a2be11 Author: Thierry Vignaud <thierry.vignaud@...> Date: Wed Jan 22 18:40:30 2014 +0100 better fix for mga#12280 while fixing exit reported by Colin previous fixes for mga#12280 resulted in Colin reporting mgaapplet exiting (not segfaulting): "When updates a bubble pops up: - If you click on the background of this bubble, mgaaplet exits - If you click on the "Install Updates" button, it pops up the password dialog. Without touching anything, about 1s later the dialog seems to be replaced with another that says "Sorry, that didn't work, please try again". When this dialog appears, mgaapplet exits." So let's clean the pile of fixes and: - have only _one_ gtk+ main loop - creating _one_ hidden notification before entering the main loop - never destroy it, but use >close + >clear_actions() then ->update() prior calling >show() when one need to show a notification again --- Commit Link: http://gitweb.mageia.org/software/mgaonline/commit/?id=87813dd7cfa302347b06cd9b0675d18577a2be11