From 46eadc7aeedf0fe3944291e2631d8604b38fe25f Mon Sep 17 00:00:00 2001 From: Chong Yidong Date: Sat, 30 Oct 2010 23:33:56 -0400 Subject: [PATCH] Print informative error message when aborting on GTK disconnect. * xterm.c (x_connection_closed): Print informative error message when aborting on GTK. This requires using shut_down_emacs directly instead of Fkill_emacs. --- src/ChangeLog | 6 +++++ src/xterm.c | 70 ++++++++++++++++++++++++--------------------------- 2 files changed, 39 insertions(+), 37 deletions(-) diff --git a/src/ChangeLog b/src/ChangeLog index cf2ae75fc8..391dc3eaa0 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,9 @@ +2010-10-31 Chong Yidong + + * xterm.c (x_connection_closed): Print informative error message + when aborting on GTK. This requires using shut_down_emacs + directly instead of Fkill_emacs. + 2010-10-25 Michael Albinus * dbusbind.c (Fdbus_call_method_asynchronously) diff --git a/src/xterm.c b/src/xterm.c index 143500256a..808eaad3f5 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -7882,48 +7882,44 @@ x_connection_closed (dpy, error_message) delete_frame (frame, Qnoelisp); } - /* We have to close the display to inform Xt that it doesn't - exist anymore. If we don't, Xt will continue to wait for - events from the display. As a consequence, a sequence of - - M-x make-frame-on-display RET :1 RET - ...kill the new frame, so that we get an IO error... - M-x make-frame-on-display RET :1 RET - - will indefinitely wait in Xt for events for display `:1', opened - in the first call to make-frame-on-display. - - Closing the display is reported to lead to a bus error on - OpenWindows in certain situations. I suspect that is a bug - in OpenWindows. I don't know how to circumvent it here. */ - + /* If DPYINFO is null, this means we didn't open the display in the + first place, so don't try to close it. */ if (dpyinfo) { #ifdef USE_X_TOOLKIT - /* If DPYINFO is null, this means we didn't open the display - in the first place, so don't try to close it. */ - { - extern void (*fatal_error_signal_hook) P_ ((void)); - fatal_error_signal_hook = x_fatal_error_signal; - XtCloseDisplay (dpy); - fatal_error_signal_hook = NULL; - } -#endif + /* We have to close the display to inform Xt that it doesn't + exist anymore. If we don't, Xt will continue to wait for + events from the display. As a consequence, a sequence of + + M-x make-frame-on-display RET :1 RET + ...kill the new frame, so that we get an IO error... + M-x make-frame-on-display RET :1 RET + + will indefinitely wait in Xt for events for display `:1', + opened in the first call to make-frame-on-display. + + Closing the display is reported to lead to a bus error on + OpenWindows in certain situations. I suspect that is a bug + in OpenWindows. I don't know how to circumvent it here. */ + extern void (*fatal_error_signal_hook) P_ ((void)); + fatal_error_signal_hook = x_fatal_error_signal; + XtCloseDisplay (dpy); + fatal_error_signal_hook = NULL; +#endif /* USE_X_TOOLKIT */ #ifdef USE_GTK - /* There is a long-standing bug in GTK that prevents the GTK - main loop from recovering gracefully from disconnects - (https://bugzilla.gnome.org/show_bug.cgi?id=85715). Among - other problems, this gives rise to a stream of Glib error - messages that, in one incident, filled up a user's hard disk - (http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00927.html). - So, kill Emacs unconditionally if the display is closed. */ - { - fprintf (stderr, "%s\n", error_msg); - Fkill_emacs (make_number (70)); - abort (); /* NOTREACHED */ - } -#endif + /* A long-standing GTK bug prevents proper disconnect handling + (https://bugzilla.gnome.org/show_bug.cgi?id=85715). Once, + the resulting Glib error message loop filled a user's disk. + To avoid this, kill Emacs unconditionally on disconnect. */ + shut_down_emacs (0, 0, Qnil); + fprintf (stderr, "%s\n\ +When compiled with GTK, Emacs cannot recover from X disconnects.\n\ +This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715\n\ +For details, see etc/PROBLEMS.\n", + error_msg); + abort (); +#endif /* USE_GTK */ /* Indicate that this display is dead. */ dpyinfo->display = 0; -- 2.20.1