Re: That old GTK bug

[Jack Kamm <jackkamm@gmail.com>]

> I think the last comment might also be implying that our problem could 
> now be caused by the abort() call it mentions that we keep around for 
> GTK 2 compatibility.

I'm way out of my depth here, but would really like to use GTK
emacsclient over SSH X forwarding, so decided to have a look at this.

To trigger the bug, I ran "emacs --fgdaemon" on latest master (9ee5af3150)
in a Debian 10 VM, then connected to it with
"ssh -XY debian10 emacsclient -nc". Then, I kill the SSH connection.

It crashes on the following code block in xterm.c: 

#ifdef USE_GTK
      /* A long-standing GTK bug prevents proper disconnect handling
	 <https://gitlab.gnome.org/GNOME/gtk/issues/221>.  Once,
	 the resulting Glib error message loop filled a user's disk.
	 To avoid this, kill Emacs unconditionally on disconnect.  */
      shut_down_emacs (0, Qnil);
      fprintf (stderr, "%s\n\
When compiled with GTK, Emacs cannot recover from X disconnects.\n\
This is a GTK bug: https://gitlab.gnome.org/GNOME/gtk/issues/221\n\
For details, see etc/PROBLEMS.\n",
	       error_msg);
      emacs_abort ();
#endif /* USE_GTK */

which is the abort call that the linked comment complains about when it
called this issue "ridiculous".

So I deleted this code block and reran my test. Emacs still crashes, but
in a different location. Here's the backtrace from gdb:

(gdb) bt
#0  0x00007ffff49135cb in raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00005555555965f8 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40)
    at emacs.c:401
#2  0x0000555555596a29 in emacs_abort () at sysdep.c:2453
#3  0x000055555559a0c7 in wait_reading_process_output
    (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5691
#4  0x00005555555a656e in sit_for
    (timeout=timeout@entry=0x7a, reading=reading@entry=true, display_option=display_option@entry=1) at lisp.h:1032
#5  0x000055555567efba in read_char
    (commandflag=1, map=0x5555581c9f03, prev_event=0x0, used_mouse_menu=0x7fffffffe03b, end_time=0x0) at lisp.h:1147
#6  0x000055555567f6ac in read_key_sequence
    (keybuf=0x7fffffffe150, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9536
#7  0x0000555555680cec in command_loop_1 () at lisp.h:1032
#8  0x00005555556e60b2 in internal_condition_case
    (bfun=bfun@entry=0x555555680b10 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x555555677d70 <cmd_error>) at eval.c:1355
#9  0x0000555555672b94 in command_loop_2 (ignore=ignore@entry=0x0) at lisp.h:1032
#10 0x00005555556e6031 in internal_catch
    (tag=tag@entry=0xd110, func=func@entry=0x555555672b70 <command_loop_2>, arg=arg@entry=0x0) at eval.c:1116
#11 0x0000555555672b3b in command_loop () at lisp.h:1032
#12 0x0000555555677976 in recursive_edit_1 () at keyboard.c:714
#13 0x0000555555677c95 in Frecursive_edit () at keyboard.c:786
#14 0x000055555559c91f in main (argc=2, argv=<optimized out>) at emacs.c:2054
(gdb)

In particular, it crashes at this call to emacs_abort() in process.c:

      if (nfds < 0)
	{
	  if (xerrno == EINTR)
	    no_avail = 1;
	  else if (xerrno == EBADF)
	    emacs_abort ();
	  else
	    report_file_errno ("Failed select", Qnil, xerrno);
	}

I don't know what this means, but I gather that emacs is crashing due to
having a bad file descriptor. So it seems like there's still some real
underlying problem here, aside from Emacs' preemptive call to abort(),
and it doesn't have anything to do with GTK 2 (as I'm using GTK 3 here).