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

[Dan Nicolaescu]

Dmitry Antipov <dmantipov@yandex.ru> writes:

> 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.

Does this happen because two TTY frames got killed at the same time
(because the xterm they were running on was killed)? 

Does emacs think that those frames are still alive? 

What is the goal when looking for frames that share the TTY ? 

[I don't know what the code in question is trying to do...]


> 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 :-(.