bug#15025: emacs --daemon stuck in infinite loop

[Dmitry Antipov]

On 08/10/2013 01:54 AM, Dan Nicolaescu wrote:

> Unfortunately I won't have time to debug this any time soon.
> But the recipe I gave shows the problem every time, so hopefully someone
> can track down the problem.

Finally I got it reproduced. Very nasty and long-standing issue (I'm pretty
sure that it was there before r111121).

The problem is that candidate_frame looks for 1) frames which shares the
keyboard for graphical frames or 2) frames which share the TTY for termcap
frames. But with Dan's example, we have:

(gdb) p XFRAME (frame)
$20 = (struct frame *) 0x108c6e0  ; argument of `next_frame'

And in Vframe_list:

(gdb) p XFRAME (XCAR (Vframe_list))
$27 = (struct frame *) 0x10756e0
(gdb) p XFRAME (XCAR (Vframe_list))->terminal
$28 = (struct terminal *) 0x1075570                         ; TTY /dev/pts/X
(gdb) p XFRAME (XCAR (Vframe_list))->output_method
$29 = output_termcap

(gdb) p XFRAME (XCAR (XCDR (Vframe_list)))
$30 = (struct frame *) 0x108c6e0
(gdb) p XFRAME (XCAR (XCDR (Vframe_list)))->terminal
$31 = (struct terminal *) 0xbeba70                          ; TTY /dev/pts/Y
(gdb) p XFRAME (XCAR (XCDR (Vframe_list)))->output_method
$32 = output_termcap

Two TTY frames on a different TTYs! So, candidate_frame always returns Qnil.

But the problem is much more interesting than redesign this:

 if ((!FRAME_TERMCAP_P (c) && !FRAME_TERMCAP_P (f)
       && FRAME_KBOARD (c) == FRAME_KBOARD (f))
      || (FRAME_TERMCAP_P (c) && FRAME_TERMCAP_P (f)
          && FRAME_TTY (c) == FRAME_TTY (f)))

IIUC, TTY "peers" (which was on xterms connected to :1) of Emacs frames becomes
invalid when Xnest dies. I suspect that we should have a method to handle such
a "TTY disconnect", but currently I have no ideas how to implement this :-(.

Dmitry