Bug 753254 - gnome-shell-extensions-alternative-status-menu crashed gnome after reboot
Summary: gnome-shell-extensions-alternative-status-menu crashed gnome after reboot
Keywords:
Status: CLOSED DUPLICATE of bug 739271
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell-extensions
Version: 16
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rahul Sundaram
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-11 18:03 UTC by gregor
Modified: 2011-11-30 17:37 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-30 17:37:23 UTC
Type: ---


Attachments (Terms of Use)

Description gregor 2011-11-11 18:03:08 UTC
Description of problem:
gnome-shell-extensions-alternative-status-menu crashed gnome after reboot

Version-Release number of selected component (if applicable):
fedora 16 3.1.0-7.fc16.x86_64
gnome 3.2.1
gnome-tweak-tool-3.2.0-1.fc16.noarch
gnome-shell-extension-alternative-status-menu-3.2.0-1.fc16.noarch

How reproducible:

Steps to Reproduce:
1. install gnome-shell-extensions-alternative-status-menu
2. install gnome-tweak-tool
3. start gnome-tweak-tool
4. enable the menu and check if it changes the menu
5. logout or reboot
6. login -> gnome crashed
  
Actual results:
gnome crashed

Expected results:
gnome shouldn't crash

Additional info:

Comment 1 Julian Stecklina 2011-11-21 20:09:56 UTC
Still applies to: gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16

Comment 2 Matt Hirsch 2011-11-30 07:40:36 UTC
Just to add to the report, I am also experiencing this. I checked out the latest git from here: git://git.gnome.org/gnome-shell-extensions

The latest alternative-status-menu extension still gives me this problem.

Also, I have a second computer running fedora 16 that does not get a crash when loading this extension. 

One (maybe inconsequential?) difference between the two is that the working one uses the proprietary nvidia graphics driver, and the non-working one uses the radeon driver.

Is there a way to see gnome-shell console errors after the "Problem"/"Logout" screen appears? Something similar to alt-f2, lg?

Comment 3 Matt Hirsch 2011-11-30 08:09:33 UTC
I did a bit of quick hacking around. The bug seems to be related to line 118 of 

/usr/share/gnome-shell/extensions/alternative-status-menu@gnome-shell-extensions.gnome.org/extension.js

from gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16.noarch

If I comment line 118 in enable(), 

    //statusMenu.menu.removeAll();

then gnome-shell doesn't crash. As expected, I do get a sort of double status menu with all the old menu items, plus the new menu items added by the extension.

Alternatively, I replaced 118 with:

    if('menu' in statusMenu) {
        statusMenu.menu.removeAll();
    }

This also avoids the crash, and causes the extension to work correctly when enabled after login. It seems clear that the problem is something related to the order of initialization of the extensions. Somehow, the alternative-status-menu extension is loaded before the menu is created on login. With the second fix there, the menu items added by alternative-status-menu are overwritten by the normal menu, so I have to disable and re-enable the extension to see the new menu. Someone with better understanding of gnome-shell should be able to fix this, I hope.

Comment 4 gregor 2011-11-30 10:59:26 UTC
(In reply to comment #3)
> I did a bit of quick hacking around. The bug seems to be related to line 118 of 
> 
> /usr/share/gnome-shell/extensions/alternative-status-menu@gnome-shell-extensions.gnome.org/extension.js
> 
> from gnome-shell-extension-alternative-status-menu-3.2.0-2.fc16.noarch
> 
> If I comment line 118 in enable(), 
> 
>     //statusMenu.menu.removeAll();
> 
> then gnome-shell doesn't crash. As expected, I do get a sort of double status
> menu with all the old menu items, plus the new menu items added by the
> extension.
> 
> Alternatively, I replaced 118 with:
> 
>     if('menu' in statusMenu) {
>         statusMenu.menu.removeAll();
>     }
> 
> This also avoids the crash, and causes the extension to work correctly when
> enabled after login. It seems clear that the problem is something related to
> the order of initialization of the extensions. Somehow, the
> alternative-status-menu extension is loaded before the menu is created on
> login. With the second fix there, the menu items added by
> alternative-status-menu are overwritten by the normal menu, so I have to
> disable and re-enable the extension to see the new menu. Someone with better
> understanding of gnome-shell should be able to fix this, I hope.

hi, 

replaced this line an it works.

THANK YOU

Comment 5 gregor 2011-11-30 11:15:01 UTC
update:
on my workstations it worked but on my laptop it crashed, there i have also the bluetooth menu icon. don't know if this is the problem

Comment 6 Matt Hirsch 2011-11-30 17:02:13 UTC
gregor, it shouldn't really work as intended, just not crash.

It seems the whole extension loading system in gnome3 is kind of a mess. These guys did some tests and found that there is no mechanism to control the order of extension loading:

http://www.consumerreports.org/cro/consumer-reports-magazine-january-2012/arsenic-in-your-juice.html

They appear to load in the order that you install them. (Perhaps in the order that they appear on the disk, e.g. ls -f).

I guess js/ui/userMenu.js is responsible for adding the menu concerned when gnome3 starts. I still don't know how to get a better measurement of when these different scripts are called, but my guess is still that somehow the alternate-status-menu extension is loaded before js/ui/userMenu.js in some circumstances.

I presume that other shell extensions could be subject to similar pitfalls. Pure speculation here, but it could be that the devs don't see this because it depends on some subtle order of file creation, and they typically don't install via rpm, which could create files in a different order than a make install.

Comment 7 Owen Taylor 2011-11-30 17:22:15 UTC
Moving to the right component; if an extension crashes gnome-shell, it's the extensions problem.

Wow, Consumer Reports was testing GNOME Shell?

(There have been some changes to how extension ordering work in the 3.4 development process.)

Comment 8 Matt Hirsch 2011-11-30 17:26:42 UTC
Haha.. Fair enough. This is what I meant to post: http://forums.linuxmint.com/viewtopic.php?f=205&t=85775&start=120

So... you do read these!

Comment 9 Mohamed El Morabity 2011-11-30 17:37:23 UTC

*** This bug has been marked as a duplicate of bug 739271 ***


Note You need to log in before you can comment on or make changes to this bug.