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 90547 - geyes hangs logout when save-session selected
geyes hangs logout when save-session selected
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.0.x
Other Solaris
: High normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-08-12 13:46 UTC by Brian Nitz
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.0


Attachments
This patch prevents geyes from hanging logout. (560 bytes, patch)
2002-08-15 11:07 UTC, Brian Nitz
none Details | Review
Traceback of geyes when it crashes on logout (crash dialog then locks up logout) (4.96 KB, text/plain)
2002-08-15 12:26 UTC, Brian Nitz
  Details
core trace of geyes with --sync (4.30 KB, text/plain)
2002-08-28 11:50 UTC, Arvind S N
  Details

Description Brian Nitz 2002-08-12 13:46:39 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.
Comment 1 Brian Nitz 2002-08-14 12:39:38 UTC
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.
Comment 2 Brian Nitz 2002-08-15 11:07:53 UTC
Created attachment 10505 [details] [review]
This patch prevents geyes from hanging logout.
Comment 3 Brian Nitz 2002-08-15 11:13:25 UTC
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.

Comment 4 Brian Nitz 2002-08-15 12:26:01 UTC
Created attachment 10506 [details]
Traceback of geyes when it crashes on logout (crash dialog then locks up logout)
Comment 5 Brian Nitz 2002-08-19 12:51:08 UTC
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.
Comment 6 Arvind S N 2002-08-26 12:50:27 UTC
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;
Comment 7 Kevin Vandersloot 2002-08-26 13:25:37 UTC
Adding Mark to the CC list since this may be a panel bug
Comment 8 Shane O'Connor 2002-08-26 16:17:20 UTC
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.

Comment 9 Mark McLoughlin 2002-08-28 09:06:25 UTC
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.
Comment 10 Michael Meeks 2002-08-28 10:40:47 UTC
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.
Comment 11 Arvind S N 2002-08-28 10:48:55 UTC
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 :-)
Comment 12 Arvind S N 2002-08-28 11:50:34 UTC
Created attachment 10763 [details]
core trace of geyes with --sync
Comment 13 Arvind S N 2002-08-28 12:09:08 UTC
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.

Comment 14 Arvind S N 2002-08-30 15:24:55 UTC
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
Comment 15 Owen Taylor 2002-09-02 03:51:01 UTC
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.

Comment 16 Kevin Vandersloot 2002-09-02 13:49:30 UTC
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
Comment 17 Mark McLoughlin 2002-09-11 21:50:27 UTC
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.