GNOME Bugzilla – Bug 576445
Adding new launcher to panel crashes Profile editor
Last modified: 2009-04-20 11:40:35 UTC
1. Right click panel, "Add to Panel..." 2. Use "Application Launcher..." or "Custom Application Launcher" to add new launcher on the panel - or - 1. Browse an application in the Applications menu 2. Right click on selected icon, "Add this launcher to panel" Both ways lead to Python traceback and Profile editor aborting. Adding new applets works fine though. Got GConf notification on '/apps/panel/objects/object_0/object_type' Delegate 'Panel' handled change '/apps/panel/objects/object_0/object_type' Got GConf notification on '/apps/panel/objects/object_0/toplevel_id' Delegate 'Panel' handled change '/apps/panel/objects/object_0/toplevel_id' Got GConf notification on '/apps/panel/objects/object_0/position' Delegate 'Panel' handled change '/apps/panel/objects/object_0/position' Got GConf notification on '/apps/panel/objects/object_0/panel_right_stick' Delegate 'Panel' handled change '/apps/panel/objects/object_0/panel_right_stick' Got GConf notification on '/apps/panel/objects/object_0/launcher_location' Delegate 'Panel' handled change '/apps/panel/objects/object_0/launcher_location' Got GConf notification on '/apps/panel/general/object_id_list' /apps/panel/general/object_id_list changed: (['object_0']) added, ([]) removed Got fatal error: Fatal exception in callback; exiting main loop Traceback (most recent call last):
+ Trace 213774
return func (*args, **kwargs)
self.COLUMN_DESCRIPTION, new_change.get_short_description ())
panel_toplevel = self.delegate.PanelToplevel(toplevel_id)
self.orientation = self.client.get_string (PANEL_KEY_BASE + "/toplevels/" + id + "/orientation")
Delegate 'Panel' handled change '/apps/panel/general/object_id_list' Terminating Exiting abnormally; dumping log due to a fatal error Got fatal error: sabayon-session exited with a FATAL ERROR (exit code 1) Fedora rawhide, Gnome 2.26 gnome-python2-gconf-2.25.90-3.fc11 sabayon-2.25.0-1.fc11 Python 2.6 (r26:66714, Feb 26 2009, 17:32:04) [GCC 4.4.0 20090219 (Red Hat 4.4.0-0.21)] on linux2
Created attachment 131248 [details] sabayon-debug-log-2009-03-24-13-03-40.txt Looks like this is not the only place where it fails. Just tested sabayon-2.25.0 on Gentoo and can't even get desktop, as it fails on startup with the same error: Delegate 'Panel' handled change '/apps/panel/objects/menu_bar_screen0/toplevel_id' Got GConf notification on '/apps/panel/general/object_id_list' /apps/panel/general/object_id_list changed: (['email_launcher_screen0', 'browser_launcher_screen0', 'menu_bar_screen0']) added, ([]) removed Got fatal error: Fatal exception in callback; exiting main loop Traceback (most recent call last):
+ Trace 213809
Got fatal error: Fatal exception in callback; exiting main loop Traceback (most recent call last): File "//usr/lib64/python2.5/site-packages/sabayon/errors.py", line 125, in wrapper return func (*args, **kwargs) File "//usr/lib64/python2.5/site-packages/sabayon/sessionwindow.py", line 89, in handle_profile_change iter = self.find (new_change.get_source (), new_change.get_id ()) File "//usr/lib64/python2.5/site-packages/sabayon/sessionwindow.py", line 129, in find if change.get_source () == source and \ AttributeError: 'NoneType' object has no attribute 'get_source' Delegate 'Panel' handled change '/apps/panel/general/object_id_list' Attaching full log for reference.
Created attachment 131249 [details] sabayon-debug-log-2009-03-24-12-46-37.txt
Created attachment 132012 [details] [review] sabayon-2.25.0-gconf-crashes.patch There's some weirdness in handling gconf events. It seems to me like changes on the panel were pushed to different gconf repository. The attached patch would make fallback to the default gconf user directory, if it couldn't get string for a thing, which should be there (we received notification from). We cannot change the gconf directory globally since the old keys are in different directory. There must be some catch elsewhere... Strange enough, I can't see the changes synced to .gconf directory when the event arrives, it takes about minute before the files are on disk. Manually requesting gconf sync doesn't make any difference. There are other problems I've noticed: - on any gconf change, the Profile -> Save menu item is not set back to sensitive - gconf isn't included in saved profile, it's somehow ignored (though I remember changing this behaviour in my last patch).
More complete patch has been posted in bug 542604. Closing this one.