GNOME Bugzilla – Bug 90547
geyes hangs logout when save-session selected
Last modified: 2004-12-22 21:47:04 UTC
Add a geyes applet to your menu panel. Logout Select "Save current setup" Logout freezes, All windows on both heads are insensitive and terminal windows don't recieve focus. It is necessary to rlogin and kill geyes in order to proceed.
Changed the priority because Geyes doesn't just hang itself, it prevents Gnome logout so the user has to login from another machine to kill geyes since all windows lose focus at this point.
Created attachment 10505 [details] [review] This patch prevents geyes from hanging logout.
Ignore the 08/15/02 07:07 attachment. This appeared to work, but the problem is intermittant and now I've seen a hang in geyes with this patch.
Created attachment 10506 [details] Traceback of geyes when it crashes on logout (crash dialog then locks up logout)
destroy_cb is invoked when: An applet is removed from a panel A panel is explicitly deleted. but it isn't always invoked when the user logs out.
Brian: This crash is due to a timer in geyes not being removed while logout.As you have rightly pointed out the destroy method is not invoked which would have removed the timer function.Infact I just noticed destroy is not called for any of the applets on logout. The solution I think should be done from the panel code :-). But I saw this crash/hang only on my linux box but not on beta 2 build 4 :/ Mark: Add this piece of code to session.c panel_session_die. It seems to have solved it. But again, would not boil down to a timing issue of gtk_widget_destroy(APPLET) and gtk_main_quit() in the panel. ? Index: gnome-panel/gnome-panel/session.c =================================================================== RCS file: /export/cvs/gnome-2.0/gnome-panel/gnome-panel/session.c,v retrieving revision 1.303 diff -u -5 -r1.303 session.c --- gnome-panel/gnome-panel/session.c 2002/08/01 00:08:38 1.303 +++ gnome-panel/gnome-panel/session.c 2002/08/26 12:35:00 @@ -236,10 +236,15 @@ panel_applet_save_position (info, info->gconf_key, TRUE); if (info->type == APPLET_BONOBO) panel_applet_frame_set_clean_remove ( PANEL_APPLET_FRAME (info->data), TRUE); + if (info->widget) { + GtkWidget *widget = info->widget; + info->widget = NULL; + gtk_widget_destroy (widget); + } } gnome_config_sync (); panel_shell_unregister (); gtk_main_quit(); return TRUE;
Adding Mark to the CC list since this may be a panel bug
I've tried this at different intervals throughout today and can't recreate this. I have geyes on the panel and have had no problems with logging out. I probably logged out aout 30 times during the day with no problems.
Arvind: when the panel process exits the panel widget's should be destroyed, and this should call the BonoboControl to be destroyed too. Maybe try and hunt down why this isn't happening. libbonoboui/doc/control.txt sets out how this should happen - although, admittedly its not exactly easy to read.
Ultimately if geyes is not dieing you should have a 'geyes' applet process somewhere; It would be interesting to see what is going on with it; it would be more interesting to see what the results of setting ORBIT2_DEBUG=traces _before_ manually running the geyes applet and then logging the results over logout.
Mark: When log out takes place. the panel is following this code path. 1) logout (logout.c) 2)panel_quit (session.c) 3)panel_session_die Destroy callback (panel_widget_destroy) is not getting genetrated for the PanelWidget as well.hope I understand your question correctly :-)
Created attachment 10763 [details] core trace of geyes with --sync
okay, found one more way of simulating this bug without the pain of a logout :/ again i am seeing this only on linux 1)Have geyes on the panel 2)Remove the panel using gnome-session-properties capplet. 3)At times the whole system hangs and when this happens u do a ps you( from the console) could see that geyes has crashed with gnome_segv handling it.
I guess the problem is BadGC error occuring which probably needs to be handled in bonobo_x_error_handler or there are problems in GtkSocket/GtkPlug. I plan to do some tests on gtk+/test/testsocket.c
While for most apps, just exiting is a fine way to clean up their resources, this is not true for apps with embedded windows: if the parent X window of an embedded X window is destroyed, the embedded X window will be destroyed as well. If the the embedded client tries to access the window before it gets the DestroyNotify, then it will get an X error. [*] Bonobo has code to mostly try and cover up this problem by adding an error handler that ignores BadWindow and BadDrawable error. But this can never be 100% reliable (without a a whole lot of work in GDK) because any code in GDK or GNOME that makes an X call would have be expected that call to possible fail. If the call is XDrawLine(), it doesn't matter; if the call is CreateGC (as it is apparently here) then arbitrarily bad things could happen. When gdk_window_destroy() is called on a window that contains an embedded window, it will unmap the embedded window, reparent the embedded window to the root window, then send it a WM_DELETE message. This allows the embedded cliented to clean up properly. It is sounding very much that when the panel exits because it receives a ::die signal from the session manager, that it doesn't clean up its windows before exiting. This is asking for crashes as described here. I don't know enough about the panel code to suggest a solution but something as simple as: for window in panel_windows: gtk_widget_destroy (window) Should do it. [*] http://www.xfree86.org/pipermail/xpert/2002-April/016954.html describes a proposal to fix this problem, but it hasn't gone anywhere yet.
I'm going to move this to gnome-panel for now since it doesn't seem to be the applets' fault. We can move it back to gnome-applets if the applet have to do something
Thanks for pointing this out Owen - I had never realised that. Of course, nothings ever as simple as that in the panel. Unfortunately the destroy handlers were being used to permanently remove the applets and panels - what a mess. Anyway, I've cleaned all that up and commit this to gnome-2-0 and HEAD: 2002-09-12 Mark McLoughlin <mark@skynet.ie> Fixes #90317 by explicitly destroying panels on receipt of a Die from the session manager rather than just exiting the mainloop. Apparently embedded out of process embedded windows don't cope with this too well - thanks to Owen for pointing this fact out. * applet.c: (panel_applet_clean): do anything required to effect permanent removal of the applet here. (applet_idle_remove): kill set_clean_remove stuff. (panel_applet_destroy): only clear up our data and refs here rather than permanently removing the applet. * basep-widget.c: remove some bogus whitepsace. * menu.c: (remove_panel_accept): if the panel is a drawer, then also remove the associated applet. Permanently remove the panel here. * panel-applet-frame.[ch]: (panel_applet_set_clean_remove), (panel_applet_get_clean_remove), (popup_handle_remove), (panel_applet_frame_instance_init): kill unused 'clean_remove' stuff. No idea how/why that got there. * panel-widget.c: (panel_widget_finalize): don't remove the panel from the global list again. (panel_widget_destroy): don't permanently remove the panel from here. * panel.c: (panel_remove_applets): kill 'clean_remove' stuff. (panel_destroy): don't remove the applet associated with the drawer here. * session.c: (panel_session_die): iterate over a copy of the global list of panels and destroy them.