[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: That old GTK bug
From: |
Jack Kamm |
Subject: |
Re: That old GTK bug |
Date: |
Sat, 14 Dec 2019 15:36:29 -0800 |
> 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).