After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672122 - Gnome Shell crash after installing extension manually and from repository in same time
Gnome Shell crash after installing extension manually and from repository in ...
Status: RESOLVED INCOMPLETE
Product: gnome-shell
Classification: Core
Component: extensions
3.3.x
Other Linux
: Normal critical
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-03-15 10:50 UTC by Martin Holec
Modified: 2012-09-09 14:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Holec 2012-03-15 10:50:55 UTC
Steps to reproduce:
1) Using Advanced Settings manually install extension from http://vhumpa.fedorapeople.org/remove-accessibility-icon@martin-weusten.de.zip
2) restart gnome-shell (using ALT+F2 and typing r)
3) Install extension from repository: "yum install gnome-shell-extension-remove-accessibility-icon"
4) restart gnome-shell (using ALT+F2 and typing r)

Actual results:
After second gnome-shell restart doesn't start at all. Need to kill session using ctrl+alt+backspace
After login gnome-shell starts with "Oh No! Something has gone wrong" dialog and remove-accessibility-icon option in list. Enabling or disabling remove-accessibility-icon doesn't make gnome-shell start to full desktop environment.

Expected Results:
gnome-shell should not crash when extension is installed manually and from repository in same time and extension is disabled
gnome-shell should load extension from ~/.local/share/gnome-shell/extensions/ at first and don't care about same extension in /usr when extension is enabled

Version:
Name        : gnome-shell
Arch        : x86_64
Version     : 3.3.90
Release     : 2.fc17
Comment 1 Giovanni Campagna 2012-03-15 17:09:46 UTC
The expected results reflect what the code is programmed to do (if the extension is already loaded, it will be ignored during directory scan).
Do you have a copy of ~/.xsession-errors showing any JS exception? Can you reproduce it under gdb and provide us stack traces for the crash during installation? (you need to so from a different virtual terminal).
And finally, are you sure this is not due to an incompatibility or bug in the extension you're installing? You cannot disable system-wide extension using the fail whale, so that would explain the inability to recover.
Comment 2 Akhil Laddha 2012-04-28 03:59:31 UTC
Martin, can you please provide requested information as per comment#1 ?
Comment 3 Tobias Mueller 2012-09-09 14:34:19 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!