Re: poor handling of multiple C-g with multi-tty (apparent hangs)

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Markus Triska]

Ami Fischman writes:

> Note that that elisp snippet is a bit extreme - in fact this behavior
> can be triggered in much more innocuous ways, such as interrupting a
> *compilation* at an inopportune moment. But I don't have a simple
> repro recipe like the above for the more mundane ways

I also encountered this problem in a normal situation; to reproduce:

1) Download http://www.logic.at/prolog/ediprolog/ediprolog.el
   and install SWI-Prolog from www.swi-prolog.org .

2) $ emacs -Q -nw -f server-start

3) $ emacsclient -c ediprolog.el
   M-x eval-buffer

4) In the *scratch* buffer, insert on a separate line:

   ?- X is 7^7^7.

   and do M-x ediprolog-dwim with point on that line. While the quite
   large number is inserted in the buffer (it takes a while), press C-g
   a few times, until the server suspends.

poor handling of multiple C-g with multi-tty (apparent hangs)

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

Emacs has code to deal with C-g being entered while a quit is already in
progress, meant to suspend emacs and drop the user to the superior shell or
debugger (see section 59.7 Emergency Escape of the emacs info).  This is
done if emacs believes it's a good idea, which criteria includes "running in
tty mode".  Unfortunately this was never updated to work correctly with the
multi-tty patch.  As a result the following can happen:
1) Start up an "emacs -Q -nw" (tty) instance and M-x server-start RET.
2) From another shell open a tty /or/ X frame to the same emacs.
3) In the second frame eval this and immediately hit C-g while the sleep-for
is running:
(let ((inhibit-quit t)
      (quit-flag t))
  (sleep-for 10))
4) The second frame becomes unresponsive because the first (main) frame has
suspended itself and dropped back to the invoking shell.

Note that that elisp snippet is a bit extreme - in fact this behavior can be
triggered in much more innocuous ways, such as interrupting a *compilation*
at an inopportune moment.  But I don't have a simple repro recipe like the
above for the more mundane ways this can trigger.

The relevant hint is in keyboard.c:handle_interrupt() which contains:
  /* XXX This code needs to be revised for multi-tty support. */
  if (!NILP (Vquit_flag)

I work around this in my personal builds by adding an "&& 0" to the end of
the if line above, which disables the feature described by 59.7.  An
alternative workaround is to not use tty frames, or start up in a tty frame
(say inside a GNU screen session), then start at least one X frame, and kill
the original tty frame, which still allows one to have a persistent emacs
server running that can be robust to the death of an X server (as long as it
is displaying a frame on at least one other X server).

This bug is very easy to tickle accidentally; every user I've converted to
multi-tty usage patterns that uses any tty frames (either inside a screen
session for persistence or over ssh connections for speed) has run afoul of
this at some point.  As things stand I believe the feature does more harm
than good.  Since 23.1 will be the first release of emacs to contain the
multi-tty functionality (advertised in NEWS as "Improved X Window System
support") I believe it should be fixed before release.  This will require
either declaring 59.7 obsolete (intentionally removing the capability) or
the attention of someone familiar with the workings of the tty code to
resolve the XXX in the code.

FWIW I remember this happening with multi-tty years ago and repros in HEAD
builds from 20080810, 20080702, and 20070829.  Also, I believe that
resolving this correctly should resolve Dan Nicolaescu's issue reported in
emacs-devel email titled '"Auto-save? (y or n)" question when doing C-z'
with Message-ID: <200807291757.m6THv4NF010142@sallyv1.ics.uci.edu>.

Cheers,
-a

[-- Attachment #2: Type: text/html, Size: 3223 bytes --]

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Chong Yidong]

"Ami Fischman" <ami@fischman.org> writes:

> Emacs has code to deal with C-g being entered while a quit is already
> in progress, meant to suspend emacs and drop the user to the superior
> shell or debugger (see section 59.7 Emergency Escape of the emacs
> info).  This is done if emacs believes it's a good idea, which
> criteria includes "running in tty mode".  Unfortunately this was never
> updated to work correctly with the multi-tty patch.

Thanks for pointing this out.

IIUC, the "emergency C-g" behavior is geared towards the traditional
setup where there's only one text-only terminal available.  There, the
emergency C-g is the only way to drop back to the shell if Emacs gets
stuck.

It's disabled for graphical terminals because there, you can open up a
separate terminal to kill/suspend the Emacs process.

This implies that we should disable the emergency C-g if Emacs is
running on more than one terminal, as in the following patch.

*** trunk/src/keyboard.c.~1.969.~	2008-08-05 17:08:23.000000000 -0400
--- trunk/src/keyboard.c	2008-08-11 13:35:43.000000000 -0400
***************
*** 10953,10958 ****
--- 10953,10976 ----
    errno = old_errno;
  }
  
+ /* If there is exactly one terminal active, return it.  Otherwise,
+    return NULL.  */
+ 
+ static struct terminal *
+ just_one_tty_p ()
+ {
+   struct terminal *t, *found = NULL;
+   for (t = terminal_list; t; t = t->next_terminal)
+     if (TERMINAL_ACTIVE_P (t))
+       {
+ 	if (found)
+ 	  return NULL;
+ 	else
+ 	  found = t;
+       }
+   return found;
+ }
+ 
  /* This routine is called at interrupt level in response to C-g.
  
     It is called from the SIGINT handler or kbd_buffer_store_event.
***************
*** 10968,10980 ****
  handle_interrupt ()
  {
    char c;
  
    cancel_echoing ();
  
-   /* XXX This code needs to be revised for multi-tty support. */
    if (!NILP (Vquit_flag)
  #ifndef MSDOS
!       && get_named_tty ("/dev/tty")
  #endif
        )
      {
--- 10986,10999 ----
  handle_interrupt ()
  {
    char c;
+   struct terminal *t;
  
    cancel_echoing ();
  
    if (!NILP (Vquit_flag)
  #ifndef MSDOS
!       && (t = just_one_tty_p (), t)
!       && t->type == output_termcap
  #endif
        )
      {

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Dan Nicolaescu]

Chong Yidong <cyd@stupidchicken.com> writes:

  > "Ami Fischman" <ami@fischman.org> writes:
  > 
  > > Emacs has code to deal with C-g being entered while a quit is already
  > > in progress, meant to suspend emacs and drop the user to the superior
  > > shell or debugger (see section 59.7 Emergency Escape of the emacs
  > > info).  This is done if emacs believes it's a good idea, which
  > > criteria includes "running in tty mode".  Unfortunately this was never
  > > updated to work correctly with the multi-tty patch.
  > 
  > Thanks for pointing this out.
  > 
  > IIUC, the "emergency C-g" behavior is geared towards the traditional
  > setup where there's only one text-only terminal available.  There, the
  > emergency C-g is the only way to drop back to the shell if Emacs gets
  > stuck.
  > 
  > It's disabled for graphical terminals because there, you can open up a
  > separate terminal to kill/suspend the Emacs process.
  > 
  > This implies that we should disable the emergency C-g if Emacs is
  > running on more than one terminal, as in the following patch.

Does this do TRT given this scenario:

ssh into a machine
enacs -nw -f server-start

then go to the console of that machine and do:

emacsclient -t

assume there's no other console and no other network connection.  If
emacs gets stuck, can you still do C-g ?

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Chong Yidong]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > This implies that we should disable the emergency C-g if Emacs is
>   > running on more than one terminal, as in the following patch.
>
> Does this do TRT given this scenario:
>
> ssh into a machine
> enacs -nw -f server-start
>
> then go to the console of that machine and do:
>
> emacsclient -t
>
> assume there's no other console and no other network connection.  If
> emacs gets stuck, can you still do C-g ?

No, and that's a problem.  But OTOH, I don't see how we can distinguish
between the two cases.  Any suggestions?

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Richard M. Stallman]

    then go to the console of that machine and do:

    emacsclient -t

-t is not documented in the Emacs manual or in the man page for
emacsclient.  Would someone please document it?

I found out what it does, from the source code,
and I think that you are right: C-g C-g should work in that case.
And it should work on the tty on which you start Emacs.

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

> This implies that we should disable the emergency C-g if Emacs is
> running on more than one terminal, as in the following patch.
>

Works for me.

Thanks,
-a

[-- Attachment #2: Type: text/html, Size: 388 bytes --]

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Ami Fischman]

[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]

This was never checked in, even though it is strictly an improvement to the
current situation (see my original email for why I believe this is an
improvement to emacs users as a whole).  Are you still working on refining
it or would you mind checking it in as it is?

-a

On Mon, Aug 11, 2008 at 10:40 AM, Chong Yidong <cyd@stupidchicken.com>wrote:

> "Ami Fischman" <ami@fischman.org> writes:
>
> > Emacs has code to deal with C-g being entered while a quit is already
> > in progress, meant to suspend emacs and drop the user to the superior
> > shell or debugger (see section 59.7 Emergency Escape of the emacs
> > info).  This is done if emacs believes it's a good idea, which
> > criteria includes "running in tty mode".  Unfortunately this was never
> > updated to work correctly with the multi-tty patch.
>
> Thanks for pointing this out.
>
> IIUC, the "emergency C-g" behavior is geared towards the traditional
> setup where there's only one text-only terminal available.  There, the
> emergency C-g is the only way to drop back to the shell if Emacs gets
> stuck.
>
> It's disabled for graphical terminals because there, you can open up a
> separate terminal to kill/suspend the Emacs process.
>
> This implies that we should disable the emergency C-g if Emacs is
> running on more than one terminal, as in the following patch.
>
> *** trunk/src/keyboard.c.~1.969.~       2008-08-05 17:08:23.000000000 -0400
> --- trunk/src/keyboard.c        2008-08-11 13:35:43.000000000 -0400
> ***************
> *** 10953,10958 ****
> --- 10953,10976 ----
>    errno = old_errno;
>  }
>
> + /* If there is exactly one terminal active, return it.  Otherwise,
> +    return NULL.  */
> +
> + static struct terminal *
> + just_one_tty_p ()
> + {
> +   struct terminal *t, *found = NULL;
> +   for (t = terminal_list; t; t = t->next_terminal)
> +     if (TERMINAL_ACTIVE_P (t))
> +       {
> +       if (found)
> +         return NULL;
> +       else
> +         found = t;
> +       }
> +   return found;
> + }
> +
>  /* This routine is called at interrupt level in response to C-g.
>
>     It is called from the SIGINT handler or kbd_buffer_store_event.
> ***************
> *** 10968,10980 ****
>  handle_interrupt ()
>  {
>    char c;
>
>    cancel_echoing ();
>
> -   /* XXX This code needs to be revised for multi-tty support. */
>    if (!NILP (Vquit_flag)
>  #ifndef MSDOS
> !       && get_named_tty ("/dev/tty")
>  #endif
>        )
>      {
> --- 10986,10999 ----
>  handle_interrupt ()
>  {
>    char c;
> +   struct terminal *t;
>
>    cancel_echoing ();
>
>    if (!NILP (Vquit_flag)
>  #ifndef MSDOS
> !       && (t = just_one_tty_p (), t)
> !       && t->type == output_termcap
>  #endif
>        )
>      {
>

[-- Attachment #2: Type: text/html, Size: 3822 bytes --]

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Eli Zaretskii]

> Date: Mon, 15 Sep 2008 16:00:39 -0700
> From: "Ami Fischman" <ami@fischman.org>
> Cc: emacs-devel@gnu.org
> 
> On Mon, Aug 11, 2008 at 10:40 AM, Chong Yidong <cyd@stupidchicken.com>wrote:
> 
> > "Ami Fischman" <ami@fischman.org> writes:
> >
> > > Emacs has code to deal with C-g being entered while a quit is already
> > > in progress, meant to suspend emacs and drop the user to the superior
> > > shell or debugger (see section 59.7 Emergency Escape of the emacs
> > > info).  This is done if emacs believes it's a good idea, which
> > > criteria includes "running in tty mode".  Unfortunately this was never
> > > updated to work correctly with the multi-tty patch.
> >
> > Thanks for pointing this out.
> >
> > IIUC, the "emergency C-g" behavior is geared towards the traditional
> > setup where there's only one text-only terminal available.  There, the
> > emergency C-g is the only way to drop back to the shell if Emacs gets
> > stuck.
> >
> > It's disabled for graphical terminals because there, you can open up a
> > separate terminal to kill/suspend the Emacs process.
> >
> > This implies that we should disable the emergency C-g if Emacs is
> > running on more than one terminal, as in the following patch.

I don't understand the problem(s) with the current code, nor the
reason why the emergency shutdown should only work when there's only
one terminal.  Perhaps the intent was to check if some of the other
terminals are non-tty's?  Could someone explain the problem and the
reasoning for the proposed solution?

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Ami Fischman]

The problem with the current code is that I can start an emacs session
in a tty at work, go home, use emacsclient to start an X frame (served
by that tty emacs at work, displayed on my X server at home), hit C-g
twice at an inopportune time, and be left with an unusable emacs,
because the tty frame has dropped back to the shell at work, but I'm
at home and unable to type the fg RET RET RET incantation into that
shell to get emacs back into the foreground.

The generalization of this scenario is that dropping an emacs process
to its invoking shell's tty is only a good idea if you're certain that
the user can reach that shell.

-a

On Mon, Sep 15, 2008 at 8:16 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 15 Sep 2008 16:00:39 -0700
>> From: "Ami Fischman" <ami@fischman.org>
>> Cc: emacs-devel@gnu.org
>>
>> On Mon, Aug 11, 2008 at 10:40 AM, Chong Yidong <cyd@stupidchicken.com>wrote:
>>
>> > "Ami Fischman" <ami@fischman.org> writes:
>> >
>> > > Emacs has code to deal with C-g being entered while a quit is already
>> > > in progress, meant to suspend emacs and drop the user to the superior
>> > > shell or debugger (see section 59.7 Emergency Escape of the emacs
>> > > info).  This is done if emacs believes it's a good idea, which
>> > > criteria includes "running in tty mode".  Unfortunately this was never
>> > > updated to work correctly with the multi-tty patch.
>> >
>> > Thanks for pointing this out.
>> >
>> > IIUC, the "emergency C-g" behavior is geared towards the traditional
>> > setup where there's only one text-only terminal available.  There, the
>> > emergency C-g is the only way to drop back to the shell if Emacs gets
>> > stuck.
>> >
>> > It's disabled for graphical terminals because there, you can open up a
>> > separate terminal to kill/suspend the Emacs process.
>> >
>> > This implies that we should disable the emergency C-g if Emacs is
>> > running on more than one terminal, as in the following patch.
>
> I don't understand the problem(s) with the current code, nor the
> reason why the emergency shutdown should only work when there's only
> one terminal.  Perhaps the intent was to check if some of the other
> terminals are non-tty's?  Could someone explain the problem and the
> reasoning for the proposed solution?
>

Re: poor handling of multiple C-g with multi-tty (apparent hangs)

[Stefan Monnier]

> This was never checked in, even though it is strictly an improvement to the
> current situation (see my original email for why I believe this is an
> improvement to emacs users as a whole).  Are you still working on refining
> it or would you mind checking it in as it is?

I think your patch is going in the right direction but isn't quite
right either.  What we should check is whether the currently active
terminal is the "controlling terminal" from which Emacs was started.

An even better fix would be that if the seletected terminal is another
tty, we should ideally also do something (e.g. pass a "suspend" message
to the emacsclient).

Basically, we want to do the suspend, but only if the selected terminal
is an output_termcap, and then we want to make sure that we suspend the
process associated with this terminal (either the main Emacs process or
one of the emacsclients).


        Stefan