diff options
author | Chong Yidong <cyd@stupidchicken.com> | 2010-10-31 10:40:01 -0400 |
---|---|---|
committer | Chong Yidong <cyd@stupidchicken.com> | 2010-10-31 10:40:01 -0400 |
commit | 2699a55464f7b43171c7b0e64d095640904e9e21 (patch) | |
tree | d99ebc74b0a108dac964f0fbcd9f9d3592ac5c6f /src | |
parent | e6ef5dd9ce13d346c7bbdcd6794b29045b4e0e63 (diff) | |
parent | 46eadc7aeedf0fe3944291e2631d8604b38fe25f (diff) |
Merge changes from emacs-23 branch
Diffstat (limited to 'src')
-rw-r--r-- | src/ChangeLog | 12 | ||||
-rw-r--r-- | src/dbusbind.c | 12 | ||||
-rw-r--r-- | src/xterm.c | 69 |
3 files changed, 57 insertions, 36 deletions
diff --git a/src/ChangeLog b/src/ChangeLog index 2d46e42e17..359869027d 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,3 +1,15 @@ +2010-10-31 Chong Yidong <cyd@stupidchicken.com> + + * 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-31 Michael Albinus <michael.albinus@gmx.de> + + * dbusbind.c (Fdbus_call_method_asynchronously) + (Fdbus_register_signal, Fdbus_register_method): Check, whether + `dbus-registered-objects-table' is initialized. + 2010-10-29 Eli Zaretskii <eliz@gnu.org> * emacs.c (main): Call syms_of_filelock unconditionally. diff --git a/src/dbusbind.c b/src/dbusbind.c index 683b7cb583..beb1faaf4a 100644 --- a/src/dbusbind.c +++ b/src/dbusbind.c @@ -1232,6 +1232,10 @@ usage: (dbus-call-method-asynchronously BUS SERVICE PATH INTERFACE METHOD HANDLE SDATA (interface), SDATA (method)); + /* Check dbus-registered-objects-table. */ + if (!HASH_TABLE_P (Vdbus_registered_objects_table)) + XD_SIGNAL1 (build_string ("dbus.el is not loaded")); + /* Open a connection to the bus. */ connection = xd_initialize (bus, TRUE); @@ -1869,6 +1873,10 @@ usage: (dbus-register-signal BUS SERVICE PATH INTERFACE SIGNAL HANDLER &rest ARG wrong_type_argument (intern ("functionp"), handler); GCPRO6 (bus, service, path, interface, signal, handler); + /* Check dbus-registered-objects-table. */ + if (!HASH_TABLE_P (Vdbus_registered_objects_table)) + XD_SIGNAL1 (build_string ("dbus.el is not loaded")); + /* Retrieve unique name of service. If service is a known name, we will register for the corresponding unique name, if any. Signals are sent always with the unique name as sender. Note: the unique @@ -1981,6 +1989,10 @@ used for composing the returning D-Bus message. */) /* TODO: We must check for a valid service name, otherwise there is a segmentation fault. */ + /* Check dbus-registered-objects-table. */ + if (!HASH_TABLE_P (Vdbus_registered_objects_table)) + XD_SIGNAL1 (build_string ("dbus.el is not loaded")); + /* Open a connection to the bus. */ connection = xd_initialize (bus, TRUE); diff --git a/src/xterm.c b/src/xterm.c index 401b3ecfa4..c7f7d036f9 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -7670,47 +7670,44 @@ x_connection_closed (Display *dpy, const char *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. */ - { - 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; |