Merge changes from emacs-23 branch

3 files changed, 57 insertions, 36 deletions

diff --git a/src/ChangeLog b/src/ChangeLog
index 2d46e42e17b..359869027dc 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 683b7cb583b..beb1faaf4aa 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 401b3ecfa4e..c7f7d036f9f 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;