GNU bug report logs - #15025
emacs --daemon stuck in infinite loop

Previous Next

Full log

View this message in rfc822 format

From: Dan Nicolaescu <dann <at> gnu.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 15025 <at> debbugs.gnu.org
Subject: bug#15025: emacs --daemon stuck in infinite loop
Date: Tue, 13 Aug 2013 10:41:20 -0400

Dmitry Antipov <dmantipov <at> 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 :-(.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.