bug#16479: 24.3.50; daemon freeze with tty menus

bug#16479: 24.3.50; daemon freeze with tty menus

[Mark Oteiza]

From emacs --daemon -Q:

$ emacsclient -t
M-x menu-bar-mode RET <F10>

At this point, the daemon is started, and a client is open with a tty
menu selected.  Leaving the first client alone, open a new one

$ emacsclient -t

Now emacs is frozen.  Here is the tail of a strace attached to the
daemon, which I helped crash by closing one of the clients.

04:10:03 open("/usr/share/emacs/24.3.50/lisp/obsolete/term/screen-256color.gz", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
04:10:03 open("/usr/share/emacs/24.3.50/lisp/term/screen.elc", O_RDONLY|O_CLOEXEC) = 15
04:10:03 fstat(15, {st_mode=S_IFREG|0644, st_size=616, ...}) = 0
04:10:03 close(15)                      = 0
04:10:03 stat("/home/mvo", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
04:10:03 write(14, "\33[H\33[J", 6)     = 6
04:10:03 --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
04:10:03 rt_sigreturn()                 = 6
04:10:03 ioctl(14, FIONREAD, [0])       = 0
04:10:03 ioctl(7, FIONREAD, [0])        = 0
04:10:03 write(14, "\33[25;1H\33[?25lWhen done with this"..., 75) = 75
04:10:03 --- SIGIO {si_signo=SIGIO, si_code=SI_TKILL, si_pid=18845, si_uid=1000} ---
04:10:03 rt_sigreturn()                 = 4611686018528051200
04:10:03 ioctl(14, FIONREAD, [0])       = 0
04:10:03 ioctl(7, FIONREAD, [0])        = 0
04:10:03 ioctl(14, FIONREAD, [0])       = 0
04:10:03 ioctl(7, FIONREAD, [0])        = 0
04:10:03 pselect6(15, [4 5 6 7 8 13 14], [], NULL, {100000, 0}, {NULL, 8}) = 1 (in [14], left {99996, 327603809})
04:10:06 ioctl(14, FIONREAD, [15746688]) = -1 EIO (Input/output error)
04:10:06 write(14, "\33[25;1H\33[K", 10) = -1 EIO (Input/output error)
04:10:06 write(14, "\33[?1l\33>\33[34h\33[?25h\33[?1049l\33[39;4"..., 35) = -1 EIO (Input/output error)
04:10:06 fdatasync(14)                  = -1 EINVAL (Invalid argument)
04:10:06 fcntl(14, F_SETFL, O_RDWR|O_LARGEFILE) = 0
04:10:06 fcntl(14, F_SETOWN, 0)         = 0
04:10:06 fcntl(14, F_GETFL)             = 0x8002 (flags O_RDWR|O_LARGEFILE)
04:10:06 fcntl(14, F_SETFL, O_RDWR|O_LARGEFILE) = 0
04:10:06 ioctl(14, SNDCTL_TMR_STOP or SNDRV_TIMER_IOCTL_GINFO or TCSETSW, {B38400 opost isig icanon echo ...}) = -1 EIO (Input/output error)
04:10:06 close(14)                      = 0
04:10:06 ioctl(7, FIONREAD, [0])        = 0
04:10:06 pselect6(14, [4 5 6 7 8 13], [], NULL, {100000, 0}, {NULL, 8}) = 1 (in [13], left {99999, 999991184})
04:10:06 read(13, "", 4096)             = 0
04:10:06 close(13)                      = 0
04:10:06 pselect6(14, [5 6 7], NULL, NULL, {0, 0}, {NULL, 8}) = 0 (Timeout)
04:10:06 ioctl(7, FIONREAD, [0])        = 0
04:10:06 pselect6(14, [4 5 6 7 8], [], NULL, {100000, 0}, {NULL, 8}) = 1 (in [7], left {99997, 207503468})
04:10:09 --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} ---
04:10:09 rt_sigreturn()                 = 1
04:10:09 ioctl(7, FIONREAD, [1])        = 0
04:10:09 read(7, "\16", 1)              = 1
04:10:09 ioctl(7, FIONREAD, [0])        = 0
04:10:09 ioctl(7, FIONREAD, [0])        = 0
04:10:09 rt_sigaction(SIGABRT, {SIG_DFL, [ABRT], SA_RESTORER|SA_RESTART, 0x7f24323773e0}, {0x4f3300, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7f24326fb870}, 8) = 0
04:10:09 getpgrp()                      = 18845
04:10:09 ioctl(0, TIOCGPGRP, [32548])   = -1 ENOTTY (Inappropriate ioctl for device)
04:10:09 close(6)                       = 0
04:10:09 close(5)                       = 0
04:10:09 open("/home/mvo/.emacs.d/auto-save-list/.saves-18845-holos.localdomain~", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 5
04:10:09 fcntl(5, F_GETFL)              = 0x8001 (flags O_WRONLY|O_LARGEFILE)
04:10:09 fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
04:10:09 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f24291d7000
04:10:09 lseek(5, 0, SEEK_CUR)          = 0
04:10:09 close(5)                       = 0
04:10:09 munmap(0x7f24291d7000, 4096)   = 0
04:10:09 rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0
04:10:09 rt_sigaction(SIGIO, {SIG_IGN, [IO], SA_RESTORER|SA_RESTART, 0x7f24323773e0}, {0x4dd260, [INT QUIT ALRM CHLD PROF WINCH IO], SA_RESTORER, 0x7f24326fb870}, 8) = 0
04:10:09 futex(0x7f24326ea1b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
04:10:09 futex(0x7f242fa123f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
04:10:09 write(2, "\nBacktrace:\n", 12) = 12
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4f41eb", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4dae5e", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4f4243", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4a47ef", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4a5b15", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4a87e8", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"460a3c", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b6fb", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"57f63d", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b1af", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b51b", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"57f63d", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b1af", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b51b", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54cb87", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"5476a3", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b6eb", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"57f63d", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b51b", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"54b84a", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4e902d", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"549b4e", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4db2ee", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"549a5b", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4df867", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"4dfb52", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"413c55", 6}, {"]\n", 2}], 4) = 16
04:10:09 writev(2, [{"/usr/lib/libc.so.6", 18}, {"(", 1}, {"__libc_start_main", 17}, {"+0x", 3}, {"f5", 2}, {")", 1}, {"[0x", 3}, {"7f2432363b05", 12}, {"]\n", 2}], 9) = 59
04:10:09 writev(2, [{"emacs", 5}, {"[0x", 3}, {"414713", 6}, {"]\n", 2}], 4) = 16
04:10:09 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
04:10:09 tgkill(18845, 18845, SIGABRT)  = 0
04:10:09 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=18845, si_uid=1000} ---
04:10:09 +++ killed by SIGABRT +++




In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars)
 of 2014-01-17 on holos
Repository revision: 
Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=lucid --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC x r e p o TAB r t TAB RET

Recent messages:
("emacs")
Starting Emacs daemon.
Loading term/xterm...done
When done with this frame, type C-x 5 0
Making completion list...
delete-backward-char: Text is read-only [4 times]

Load-path shadows:
/usr/share/emacs/site-lisp/timeclock hides /usr/share/emacs/24.3.50/lisp/calendar/timeclock

Features:
(shadow sort gnus-util mail-extr emacsbug message idna format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils help-mode easymenu xterm server
windmove edmacro kmacro cl-loaddefs cl-lib time-date paren zenburn-theme
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 17 Jan 2014 04:39:55 -0500
> 
> 
> >From emacs --daemon -Q:
> 
> $ emacsclient -t
> M-x menu-bar-mode RET <F10>
> 
> At this point, the daemon is started, and a client is open with a tty
> menu selected.  Leaving the first client alone, open a new one
> 
> $ emacsclient -t
> 
> Now emacs is frozen.

It's not frozen, it waits for you to finish the menu input.  The same
happens if you type, e.g., "C-x" in one client and then switch to the
other: it will be unresponsive until you finish typing the command in
the first one.

Emacs reads only from one keyboard at a time.

This is not a bug, but a well-known limitation of multi-tty input in
Emacs.

bug#16479: 24.3.50; daemon freeze with tty menus

[Mark Oteiza]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Mark Oteiza <mvoteiza@udel.edu>
>> Date: Fri, 17 Jan 2014 04:39:55 -0500
>> 
>> 
>> >From emacs --daemon -Q:
>> 
>> $ emacsclient -t
>> M-x menu-bar-mode RET <F10>
>> 
>> At this point, the daemon is started, and a client is open with a tty
>> menu selected.  Leaving the first client alone, open a new one
>> 
>> $ emacsclient -t
>> 
>> Now emacs is frozen.
>
> It's not frozen, it waits for you to finish the menu input.  The same
> happens if you type, e.g., "C-x" in one client and then switch to the
> other: it will be unresponsive until you finish typing the command in
> the first one.
>
> Emacs reads only from one keyboard at a time.
>
> This is not a bug, but a well-known limitation of multi-tty input in
> Emacs.

Ok.  I understand that emacs has to wait for input.  With menu-bar-mode
disabled, I can open a menu in client A with F10, open another client B
somewhere else, return to client A and do whatever with the menu.

With menu-bar-mode (and thus the new tty menus) enabled, if I do the
steps I outlined above, I expect to be able to return to the previous
client and finish input.  This is not the case: if I go back to the
first client with the menu, and try an arrow key or C-{npbf}, emacs
crashes.  I think this is a bug.

I realize I failed to communicate the problem in my first email.

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Fri, 17 Jan 2014 05:21:51 -0500
> 
> > It's not frozen, it waits for you to finish the menu input.  The same
> > happens if you type, e.g., "C-x" in one client and then switch to the
> > other: it will be unresponsive until you finish typing the command in
> > the first one.
> >
> > Emacs reads only from one keyboard at a time.
> >
> > This is not a bug, but a well-known limitation of multi-tty input in
> > Emacs.
> 
> Ok.  I understand that emacs has to wait for input.  With menu-bar-mode
> disabled, I can open a menu in client A with F10, open another client B
> somewhere else, return to client A and do whatever with the menu.
> 
> With menu-bar-mode (and thus the new tty menus) enabled, if I do the
> steps I outlined above, I expect to be able to return to the previous
> client and finish input.  This is not the case: if I go back to the
> first client with the menu, and try an arrow key or C-{npbf}, emacs
> crashes.  I think this is a bug.

A crash is always a bug.

I understand that you are talking about the situation where the menu
is already open on one client, and then you start another client.

If so, this seems to have something to do with the fact that starting
a client writes something to the terminal (to query the terminal about
its features).

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> Date: Fri, 17 Jan 2014 13:10:43 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 16479@debbugs.gnu.org
> 
> > With menu-bar-mode (and thus the new tty menus) enabled, if I do the
> > steps I outlined above, I expect to be able to return to the previous
> > client and finish input.  This is not the case: if I go back to the
> > first client with the menu, and try an arrow key or C-{npbf}, emacs
> > crashes.  I think this is a bug.
> 
> A crash is always a bug.
> 
> I understand that you are talking about the situation where the menu
> is already open on one client, and then you start another client.
> 
> If so, this seems to have something to do with the fact that starting
> a client writes something to the terminal (to query the terminal about
> its features).

I tried to fix this in trunk revision 116053.  It is still not ideal
(but what _is_ the ideal in this case?): the open menu pops down, and
you need to type C-g in the client where the menu was open to get out,
but at least the daemon doesn't segfault.

Stefan, can you suggest a better solution?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

> I tried to fix this in trunk revision 116053.

That looks correct, thank you.

> It is still not ideal (but what _is_ the ideal in this case?): the
> open menu pops down, and you need to type C-g in the client where the
> menu was open to get out, but at least the daemon doesn't segfault.

Hmm... connecting with another emacsclient causes the menu to pop down,
but you still have to additionally hit C-g to "really get out"?
That's weird.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Fri, 17 Jan 2014 09:55:13 -0500
> 
> > I tried to fix this in trunk revision 116053.
> 
> That looks correct, thank you.

Beginner's luck.

> > It is still not ideal (but what _is_ the ideal in this case?): the
> > open menu pops down, and you need to type C-g in the client where the
> > menu was open to get out, but at least the daemon doesn't segfault.
> 
> Hmm... connecting with another emacsclient causes the menu to pop down,
> but you still have to additionally hit C-g to "really get out"?
> That's weird.

Somehow Emacs still thinks it's inside the menu (it displays the help
echo in the echo area).  I guess something is missing somewhere, or
maybe some global variable is not reset as it should.

Why does the connection attempt from the second client accepted when
we switch to a single keyboard?  I expected it to be rejected.  What
am I missing?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

> Why does the connection attempt from the second client accepted when
> we switch to a single keyboard?  I expected it to be rejected.

I don't think we have a mechanism to reject it (and usually it wouldn't
be the right thing to do either, because in most cases there's only
a single physical user behind the two connections, so the most recent
one is the one she cares about right now).

Instead, emacsclient does:

  (when (> (recursion-depth) 0)
    ;; We're inside a minibuffer already, so if the emacs-client is trying
    ;; to open a frame on a new display, we might end up with an unusable
    ;; frame because input from that display will be blocked (until exiting
    ;; the minibuffer).  Better exit this minibuffer right away.
    ;; Similarly with recursive-edits such as the splash screen.
    (run-with-timer 0 nil (lambda () (server-execute-continuation proc)))
    (top-level)))

So, ideally (recursion-depth) should be >0 when inside the tty menus,
and calling (top-level) should get us out of that tty menu.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Fri, 17 Jan 2014 11:16:26 -0500
> 
> So, ideally (recursion-depth) should be >0 when inside the tty menus,
> and calling (top-level) should get us out of that tty menu.

I'll see what I can do.  Thanks.

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> Date: Fri, 17 Jan 2014 20:54:46 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: mvoteiza@udel.edu, 16479@debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> > Date: Fri, 17 Jan 2014 11:16:26 -0500
> > 
> > So, ideally (recursion-depth) should be >0 when inside the tty menus,
> > and calling (top-level) should get us out of that tty menu.
> 
> I'll see what I can do.  Thanks.

I think I see the root cause.  It's in server-create-tty-frame, which
does:

    (set-frame-parameter frame 'display
                         (getenv-internal "DISPLAY" (process-get proc 'env)))
    (select-frame frame)

IOW, it switches to the newly created TTY frame from under the feet of
the menu input loop.  When read_menu_command returns, the selected
frame is different from what it was when the function was called.

It is easy enough to detect the frame switch, but the question is:
what to do when that happens?

This is complicated by the fact that the frame switch event is not
returned until some other event takes place.  Thus, while the new
frame is already selected, the old frame still has focus, until you
type something.  So to exit the vicious circle, you need to type
something into the old frame (which causes the new frame to react),
then switch to the new frame, and only then you are out of the woods.

I'm unsure how best to handle this mess.  Maybe avoid selecting the
new frame in server-create-tty-frame, if a TTY menu is currently being
displayed?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

> I'm unsure how best to handle this mess.  Maybe avoid selecting the
> new frame in server-create-tty-frame, if a TTY menu is currently being
> displayed?

Whatever we do, we should do it whether or not a tty menu is displayed.
Switching frame inside a process filter is nasty but allowed.  So:
- server.el should probably only change the selected frame temporarily and
  revert it before returning from the process filter.
- tty menus need to make sure they don't crash if a process filter
  changes the selected frame.  But I think it's OK if they behave a bit
  strangely in that case.  IIUC with your recent change it doesn't crash
  any more, so it might be good enough on this side.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Mon, 20 Jan 2014 13:27:00 -0500
> 
> > I'm unsure how best to handle this mess.  Maybe avoid selecting the
> > new frame in server-create-tty-frame, if a TTY menu is currently being
> > displayed?
> 
> Whatever we do, we should do it whether or not a tty menu is displayed.
> Switching frame inside a process filter is nasty but allowed.  So:
> - server.el should probably only change the selected frame temporarily and
>   revert it before returning from the process filter.

But I think server.el does this on purpose: if it didn't switch to the
new frame, you couldn't start typing into it after invoking
emacsclient, even when there's no menu displayed.  Wouldn't that be
confusing?

> - tty menus need to make sure they don't crash if a process filter
>   changes the selected frame.

That is easy.

>   But I think it's OK if they behave a bit strangely in that case.

Does the fact that you type into one frame and get response in another
count as "a bit strangely"?  Then we don't need to do anything except
to add some simple detection of the frame switch, see below.

>   IIUC with your recent change it doesn't crash any more, so it
>   might be good enough on this side.

The crash happened because the frame switch went unnoticed, and we
tried to use face IDs from one frame on another.  This no longer
happens, and I will add a simple code that will quit the menu when it
sees a frame switch.

Thanks.

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

>> Whatever we do, we should do it whether or not a tty menu is displayed.
>> Switching frame inside a process filter is nasty but allowed.  So:
>> - server.el should probably only change the selected frame temporarily and
>> revert it before returning from the process filter.
> But I think server.el does this on purpose: if it didn't switch to the
> new frame, you couldn't start typing into it after invoking
> emacsclient, even when there's no menu displayed.  Wouldn't that be
> confusing?

I'm not sure it's the case.  The reason is that you're talking about
a change of focus whereas the code changed the selected frame.  The two
are related but the relation is very murky.

> Does the fact that you type into one frame and get response in another
> count as "a bit strangely"?

Yes.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Mon, 20 Jan 2014 15:28:42 -0500
> 
> >> Whatever we do, we should do it whether or not a tty menu is displayed.
> >> Switching frame inside a process filter is nasty but allowed.  So:
> >> - server.el should probably only change the selected frame temporarily and
> >> revert it before returning from the process filter.
> > But I think server.el does this on purpose: if it didn't switch to the
> > new frame, you couldn't start typing into it after invoking
> > emacsclient, even when there's no menu displayed.  Wouldn't that be
> > confusing?
> 
> I'm not sure it's the case.  The reason is that you're talking about
> a change of focus whereas the code changed the selected frame.  The two
> are related but the relation is very murky.
> 
> > Does the fact that you type into one frame and get response in another
> > count as "a bit strangely"?
> 
> Yes.

OK, then I know what to do.  Thanks.

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> Date: Mon, 20 Jan 2014 23:17:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: mvoteiza@udel.edu, 16479@debbugs.gnu.org
> 
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> > Date: Mon, 20 Jan 2014 15:28:42 -0500
> > 
> > >> Whatever we do, we should do it whether or not a tty menu is displayed.
> > >> Switching frame inside a process filter is nasty but allowed.  So:
> > >> - server.el should probably only change the selected frame temporarily and
> > >> revert it before returning from the process filter.
> > > But I think server.el does this on purpose: if it didn't switch to the
> > > new frame, you couldn't start typing into it after invoking
> > > emacsclient, even when there's no menu displayed.  Wouldn't that be
> > > confusing?
> > 
> > I'm not sure it's the case.  The reason is that you're talking about
> > a change of focus whereas the code changed the selected frame.  The two
> > are related but the relation is very murky.
> > 
> > > Does the fact that you type into one frame and get response in another
> > > count as "a bit strangely"?
> > 
> > Yes.
> 
> OK, then I know what to do.  Thanks.

Or maybe not.  I did what I thought was needed (see bzr r116153), but
there's still a problem with restoring the original value of
overriding-terminal-local-map after popping down the menu.  E.g., in
this scenario:

  emacs -Q -nw
  M-x server-start
  F10

then in another terminal:

  emacsclient -t

This pops down the menu, but the value of
overriding-terminal-local-map in the original frame is not restored,
so, for example, any cursor motion command signals an error because it
tries to invoke tty-menu commands.

What am I not doing correctly here?  TIA.

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

>   emacsclient -t
> This pops down the menu, but the value of
> overriding-terminal-local-map in the original frame is not restored,
> so, for example, any cursor motion command signals an error because it
> tries to invoke tty-menu commands.
> What am I not doing correctly here?  TIA.

Maybe there's a bug in our handling of let-binding w.r.t terminal-local
variables (i.e. the unbind of overriding-terminal-local-map ands up
resetting that variable in the new terminal rather than in the terminal
where the specbind was done).

I can't remember seeing code to handle that when I last touched the
let-binding code, so it sounds very likely: we try and handle
buffer-local and frame-local correctly (by remembering where the
binding was installed a de-install it at the right place) but we don't
do that same thing for terminal-local bindings.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Sat, 25 Jan 2014 17:39:16 -0500
> 
> >   emacsclient -t
> > This pops down the menu, but the value of
> > overriding-terminal-local-map in the original frame is not restored,
> > so, for example, any cursor motion command signals an error because it
> > tries to invoke tty-menu commands.
> > What am I not doing correctly here?  TIA.
> 
> Maybe there's a bug in our handling of let-binding w.r.t terminal-local
> variables (i.e. the unbind of overriding-terminal-local-map ands up
> resetting that variable in the new terminal rather than in the terminal
> where the specbind was done).
> 
> I can't remember seeing code to handle that when I last touched the
> let-binding code, so it sounds very likely: we try and handle
> buffer-local and frame-local correctly (by remembering where the
> binding was installed a de-install it at the right place) but we don't
> do that same thing for terminal-local bindings.

Could this be related to the fact that Voverriding_terminal_local_map
is a per-keyboard variable?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

>> do that same thing for terminal-local bindings.
> Could this be related to the fact that Voverriding_terminal_local_map
> is a per-keyboard variable?

Right: "terminal-local" == "per-keyboard".


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Sun, 26 Jan 2014 01:17:12 -0500
> 
> >> do that same thing for terminal-local bindings.
> > Could this be related to the fact that Voverriding_terminal_local_map
> > is a per-keyboard variable?
> 
> Right: "terminal-local" == "per-keyboard".

Any guidance as to how to solve this?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

>> >> do that same thing for terminal-local bindings.
>> > Could this be related to the fact that Voverriding_terminal_local_map
>> > is a per-keyboard variable?
>> Right: "terminal-local" == "per-keyboard".
> Any guidance as to how to solve this?

In specbind we need to add special handling for "per-keyboard variables"
by setting the `where' slot to hold the corresponding keyboard.
And then in all the places where the `where' slot is used, adjust the
code to handle the case where it holds a keyboard rather than a buffer
(or a frame).

One problem will bite us along the way: keyboards are not visible as
Lisp_Object objects.  You'll have to store in `where' the terminal
object instead.

The distinction between keyboards and terminals is subtle.  In 99.9% of
the cases, there's a one-to-one correspondence between the two, the 0.1%
remaining is when you have an X server with 2 "screens" (this is
"screen" in the X11 sense, i.e. one has name ":0.0" and the other
":0.1"), in which case we will have two terminals for a single keyboard.

So storing the terminal instead of the keyword is correct in 99.9% of
the cases.  And to tell you the truth, this subtlety is much too subtle
for us, so we have such "errors" in many other places.  As I mentioned in
the past in some other thread, we should simply get rid of this subtlety,
i.e. get rid of the distinction between terminals and keyboards.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mvoteiza@udel.edu,  16479@debbugs.gnu.org
> Date: Sun, 26 Jan 2014 21:07:20 -0500
> 
> In specbind we need to add special handling for "per-keyboard variables"
> by setting the `where' slot to hold the corresponding keyboard.
> And then in all the places where the `where' slot is used, adjust the
> code to handle the case where it holds a keyboard rather than a buffer
> (or a frame).
> 
> One problem will bite us along the way: keyboards are not visible as
> Lisp_Object objects.  You'll have to store in `where' the terminal
> object instead.

Will such changes be acceptable during the feature freeze?  Or should
I wait until after the branch?

bug#16479: 24.3.50; daemon freeze with tty menus

[Stefan Monnier]

>> One problem will bite us along the way: keyboards are not visible as
>> Lisp_Object objects.  You'll have to store in `where' the terminal
>> object instead.
> Will such changes be acceptable during the feature freeze?

Using the `where' slot for these variables can definitely be fixed now.
We don't want new features, but we do want bug-fixes.


        Stefan

bug#16479: 24.3.50; daemon freeze with tty menus

[Lars Ingebrigtsen]

Mark Oteiza <mvoteiza@udel.edu> writes:

>>From emacs --daemon -Q:
>
> $ emacsclient -t
> M-x menu-bar-mode RET <F10>
>
> At this point, the daemon is started, and a client is open with a tty
> menu selected.  Leaving the first client alone, open a new one
>
> $ emacsclient -t
>
> Now emacs is frozen.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I'm unable to reproduce this with Emacs 29.  Are you still seeing this
issue with recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16479: 24.3.50; daemon freeze with tty menus

[Mark Oteiza]

On 23/04/22 at 04:09pm, Lars Ingebrigtsen wrote:
> Mark Oteiza <mvoteiza@udel.edu> writes:
> 
> >>From emacs --daemon -Q:
> >
> > $ emacsclient -t
> > M-x menu-bar-mode RET <F10>
> >
> > At this point, the daemon is started, and a client is open with a tty
> > menu selected.  Leaving the first client alone, open a new one
> >
> > $ emacsclient -t
> >
> > Now emacs is frozen.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> I'm unable to reproduce this with Emacs 29.  Are you still seeing this
> issue with recent Emacs versions?

No, I am also unable to reproduce. Thanks

bug#16479: 24.3.50; daemon freeze with tty menus

[Lars Ingebrigtsen]

Mark Oteiza <mvoteiza@udel.edu> writes:

> No, I am also unable to reproduce. Thanks

Thanks for checking; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no