aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorChong Yidong2010-10-25 12:08:27 -0400
committerChong Yidong2010-10-25 12:08:27 -0400
commit931c1dfaae8e1fc4c77e563912ee4fb5953ae844 (patch)
treec7aa81bb83862a6648b70f20c66e9214d77034b2
parent655441b28ae5dd95c4a889a92a9be0f9cab2cf0d (diff)
downloademacs-931c1dfaae8e1fc4c77e563912ee4fb5953ae844.tar.gz
emacs-931c1dfaae8e1fc4c77e563912ee4fb5953ae844.zip
Document GTK Emacs kill on display close in PROBLEMS.
* src/xterm.c (x_connection_closed): Expand comment.
-rw-r--r--etc/PROBLEMS19
-rw-r--r--src/xterm.c8
2 files changed, 16 insertions, 11 deletions
diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index fb1b2b38d56..6fd959b00b7 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -241,19 +241,18 @@ necessary but missing, please report it via M-x report-emacs-bug.
241On platforms such as Solaris, you can also work around this problem by 241On platforms such as Solaris, you can also work around this problem by
242configuring your compiler to use the native linker instead of GNU ld. 242configuring your compiler to use the native linker instead of GNU ld.
243 243
244** Emacs compiled with Gtk+ crashes when closing a display (x-close-connection). 244** When Emacs is compiled with Gtk+, closing a display kills Emacs.
245 245
246This happens because of bugs in Gtk+. Gtk+ 2.10 seems to be OK. See bug 246There is a long-standing bug in GTK that prevents it from recovering
247http://bugzilla.gnome.org/show_bug.cgi?id=85715. 247from disconnects: http://bugzilla.gnome.org/show_bug.cgi?id=85715.
248 248
249** Emacs compiled with Gtk+ may loop forever if a display crashes. 249Thus, for instance, when Emacs is run as a server on a text terminal,
250and an X frame is created, and the X server for that frame crashes or
251exits unexpectedly, Emacs must exit to prevent a GTK error that would
252result in an endless loop.
250 253
251This is related to the bug above. A scenario for this is when emacs is run 254If you need Emacs to be able to recover from closing displays, compile
252as a server, and an X frame is created. If the X server for the frame 255it with the Lucid toolkit instead of GTK.
253crashes or exits unexpectedly and an attempt is made to create a new
254frame on another X display, then a Gtk+ error happens in the emacs
255server that results in an endless loop. This is not fixed in any known
256Gtk+ version (2.14.4 being current).
257 256
258* General runtime problems 257* General runtime problems
259 258
diff --git a/src/xterm.c b/src/xterm.c
index 1de49e2fde1..143500256a1 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -7911,7 +7911,13 @@ x_connection_closed (dpy, error_message)
7911#endif 7911#endif
7912 7912
7913#ifdef USE_GTK 7913#ifdef USE_GTK
7914 /* Due to bugs in some Gtk+ versions, just exit here. */ 7914 /* There is a long-standing bug in GTK that prevents the GTK
7915 main loop from recovering gracefully from disconnects
7916 (https://bugzilla.gnome.org/show_bug.cgi?id=85715). Among
7917 other problems, this gives rise to a stream of Glib error
7918 messages that, in one incident, filled up a user's hard disk
7919 (http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00927.html).
7920 So, kill Emacs unconditionally if the display is closed. */
7915 { 7921 {
7916 fprintf (stderr, "%s\n", error_msg); 7922 fprintf (stderr, "%s\n", error_msg);
7917 Fkill_emacs (make_number (70)); 7923 Fkill_emacs (make_number (70));