bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Len Trigg]

[-- Attachment #1.1: Type: text/plain, Size: 5385 bytes --]

tty-child-frames does not seem to play well with multiple clients. When we
run server-start and allow emacs to have multiple clients (e.g. an initial
"emacs -nw" and an
"emacsclient -nw"), using a function that utilizes tty-child-frame (such as
M-x when vertico-posframe is loaded) in one frame leads the other client to
be locked up.

Steps to reproduce:

mkdir ~/emacs-test
Copy the attached init.el into ~/emacs-test/
emacs -nw --init-directory=~/emacs-test  (the first time will result in
packages being installed by elpaca)
(in another terminal) emacsclient -nw
Do something to invoke the child frame pop up (e.g. C-x b and select a
buffer)
Switch back to the original emacs
Do something to invoke the child frame pop up (e.g. C-x b and select a
buffer)
Swap to the other terminal, and note that at some point one client will
stop responding
to user input. (It may take a couple of tries, perhaps with other regular
commands interspersed).
When one client is locked, swap back to the other terminal and exit the
client - the original
client will now accept user input.

When a client is locked it *does* accept some input (e.g. C-x C-c will exit
the client)

It's possible this is vertico-posframe related, as I can't trigger similar
behaviour using transient-posframe.


In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-12-24 built on kaka
Repository revision: 6ac38396898e6324d4c6dddb2ad05d1ad0dc5e7c
Repository branch: master
System Description: Ubuntu 24.04.1 LTS

Configured using:
 'configure --prefix=/home/len/.local --with-rsvg --with-cairo
 --with-native-compilation --with-tree-sitter --with-modules'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP
NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_AU.UTF-8
  value of $LC_NUMERIC: en_AU.UTF-8
  value of $LC_TIME: en_AU.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  xterm-mouse-mode: t
  server-mode: t
  vertico-posframe-mode: t
  vertico-mode: t
  elpaca-use-package-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run
comp-common rx emacsbug message yank-media puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils xt-mouse term/xterm xterm
server vertico-posframe vertico-multiform vertico compat posframe
vertico-posframe-autoloads vertico-autoloads posframe-autoloads cl-extra
help-mode elpaca-use-package use-package use-package-ensure
use-package-delight use-package-diminish use-package-bind-key bind-key
easy-mmode use-package-core elpaca-use-package-autoloads elpaca-log
elpaca-ui elpaca-menu-elpa elpaca-menu-melpa url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars mailcap elpaca-menu-org elpaca warnings icons elpaca-process
cl-loaddefs cl-lib elpaca-autoloads rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/x-win x-win term/common-win x-dnd touch-screen tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
tty-child-frames native-compile emacs)

Memory information:
((conses 16 396223 19518) (symbols 48 15669 0)
 (strings 32 187599 3392) (string-bytes 1 2901786) (vectors 16 17588)
 (vector-slots 8 194405 8250) (floats 8 78 41) (intervals 56 346 0)
 (buffers 992 19))

[-- Attachment #1.2: Type: text/html, Size: 5923 bytes --]

[-- Attachment #2: init.el --]
[-- Type: text/x-emacs-lisp, Size: 3630 bytes --]

;;; init.el --- Emacs initialization

;;; Code:

;; elpaca boilerplate ;;
(setq package-enable-at-startup nil)
;; Use elpaca rather than package.el, it gives better control over package versions
(defvar elpaca-installer-version 0.8)
(defvar elpaca-directory (expand-file-name "elpaca/" user-emacs-directory))
(defvar elpaca-builds-directory (expand-file-name "builds/" elpaca-directory))
(defvar elpaca-repos-directory (expand-file-name "repos/" elpaca-directory))
(defvar elpaca-order '(elpaca :repo "https://github.com/progfolio/elpaca.git"
                              :ref nil :depth 1
                              :files (:defaults "elpaca-test.el" (:exclude "extensions"))
                              :build (:not elpaca--activate-package)))
(let* ((repo  (expand-file-name "elpaca/" elpaca-repos-directory))
       (build (expand-file-name "elpaca/" elpaca-builds-directory))
       (order (cdr elpaca-order))
       (default-directory repo))
  (add-to-list 'load-path (if (file-exists-p build) build repo))
  (unless (file-exists-p repo)
    (make-directory repo t)
    (when (< emacs-major-version 28) (require 'subr-x))
    (condition-case-unless-debug err
        (if-let* ((buffer (pop-to-buffer-same-window "*elpaca-bootstrap*"))
                  ((zerop (apply #'call-process `("git" nil ,buffer t "clone"
                                                  ,@(when-let* ((depth (plist-get order :depth)))
                                                      (list (format "--depth=%d" depth) "--no-single-branch"))
                                                  ,(plist-get order :repo) ,repo))))
                  ((zerop (call-process "git" nil buffer t "checkout"
                                        (or (plist-get order :ref) "--"))))
                  (emacs (concat invocation-directory invocation-name))
                  ((zerop (call-process emacs nil buffer nil "-Q" "-L" "." "--batch"
                                        "--eval" "(byte-recompile-directory \".\" 0 'force)")))
                  ((require 'elpaca))
                  ((elpaca-generate-autoloads "elpaca" repo)))
            (progn (message "%s" (buffer-string)) (kill-buffer buffer))
          (error "%s" (with-current-buffer buffer (buffer-string))))
      ((error) (warn "%s" err) (delete-directory repo 'recursive))))
  (unless (require 'elpaca-autoloads nil t)
    (require 'elpaca)
    (elpaca-generate-autoloads "elpaca" repo)
    (load "./elpaca-autoloads")))
(add-hook 'after-init-hook #'elpaca-process-queues)
(elpaca `(,@elpaca-order))

;; Install use-package support
(elpaca elpaca-use-package
  ;; Enable :elpaca use-package keyword.
  (elpaca-use-package-mode)
  ;; Assume :elpaca t unless otherwise specified.
  (setq elpaca-use-package-by-default t))

;; Block until current queue processed.
(elpaca-wait)

;; (setq custom-file (expand-file-name "custom.el" user-emacs-directory))
;; (add-hook 'elpaca-after-init-hook (lambda () (load custom-file 'noerror)))


(use-package posframe
  ;;:config
  ;;(setq posframe-mouse-banish nil)
  )
(use-package vertico-posframe
  :after posframe vertico
  :config
  (push '(tty-non-selected-cursor . t) vertico-posframe-parameters)
  (push '(background-color . "black") vertico-posframe-parameters)
  (push '(undecorated . nil) vertico-posframe-parameters)
    (vertico-posframe-mode))

(use-package vertico
  :init
  (vertico-mode)
  ;;(advice-add #'tmm-add-prompt :after #'minibuffer-hide-completions)
  ;; (setq
  ;;  vertico-resize nil
  ;;  vertico-cycle t)
  )

(use-package server
  :ensure nil
  :hook (elpaca-after-init . server-start))

;;; init.el ends here

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> From: Len Trigg <lenbok@gmail.com>
> Date: Tue, 24 Dec 2024 18:43:29 +1300
> 
> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to
> have multiple clients (e.g. an initial "emacs -nw" and an
> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is
> loaded) in one frame leads the other client to be locked up.
> 
> Steps to reproduce:
> 
> mkdir ~/emacs-test
> Copy the attached init.el into ~/emacs-test/
> emacs -nw --init-directory=~/emacs-test  (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Switch back to the original emacs
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Swap to the other terminal, and note that at some point one client will stop responding
> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
> When one client is locked, swap back to the other terminal and exit the client - the original
> client will now accept user input.
> 
> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
> 
> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.

Gerd, could you perhaps look into this?

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Len Trigg <lenbok@gmail.com>
>> Date: Tue, 24 Dec 2024 18:43:29 +1300
>> 
>> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to
>> have multiple clients (e.g. an initial "emacs -nw" and an
>> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is
>> loaded) in one frame leads the other client to be locked up.
>> 
>> Steps to reproduce:
>> 
>> mkdir ~/emacs-test
>> Copy the attached init.el into ~/emacs-test/
>> emacs -nw --init-directory=~/emacs-test  (the first time will result in packages being installed by elpaca)
>> (in another terminal) emacsclient -nw
>> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
>> Switch back to the original emacs
>> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
>> Swap to the other terminal, and note that at some point one client will stop responding
>> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
>> When one client is locked, swap back to the other terminal and exit the client - the original
>> client will now accept user input.
>> 
>> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>> 
>> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
>
> Gerd, could you perhaps look into this?

Thanks. Will come back to this after the holidays.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Len Trigg <lenbok@gmail.com> writes:

> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to have
> multiple clients (e.g. an initial "emacs -nw" and an
> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is loaded) in one
> frame leads the other client to be locked up.
>
> Steps to reproduce:
>
> mkdir ~/emacs-test
> Copy the attached init.el into ~/emacs-test/
> emacs -nw --init-directory=~/emacs-test  (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Switch back to the original emacs
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Swap to the other terminal, and note that at some point one client will stop responding
> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
> When one client is locked, swap back to the other terminal and exit the client - the original
> client will now accept user input.
>
> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>
> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
>

Hi Len, and thanks for the nice reproducer!

I can reproduce what you describe, I think, but I must admit that I'm a
bit at a loss at the moment. Something similar happens BTW if the server
is a GUI Emacs. Pretty weird.

And then I found this in admin/notes/multi-tty, under known problems:

        * The single-kboard mode.

	  If your multi-tty Emacs session seems to be frozen, you
	  probably have a recursive editing session or a pending
	  minibuffer prompt (which is a kind of recursive editing) on
	  another display.  To unfreeze your session, switch to that
	  display and complete the recursive edit, for example by
	  pressing C-] ('abort-recursive-edit').

	  I am sorry to say that currently there is no way to break
	  out of this "single-kboard mode" from a frozen display.  If
	  you are unable to switch to the display that locks the
	  others (for example because it is on a remote computer),
	  then you can use emacsclient to break out of all recursive
	  editing sessions:

		emacsclient -e '(top-level)'

	  Note that this (perhaps) unintuitive behavior is by design.
	  Single-kboard mode is required because of an intrinsic Emacs
	  limitation that is very hard to eliminate.  (This limitation
	  is related to the single-threaded nature of Emacs.)

	  I plan to implement better user notification and support for
	  breaking out of single-kboard mode from locked displays.

Also see the long list of things to do in the same file, which makes me
a bit wary.

@Eli: I think we should invoke a multi-tty expert who can tell if what
we see here can be kind of expected with the current state of multi-tty or
not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
first place.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> Cc: 75056@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 27 Dec 2024 07:04:54 +0100
> 
> I can reproduce what you describe, I think, but I must admit that I'm a
> bit at a loss at the moment. Something similar happens BTW if the server
> is a GUI Emacs. Pretty weird.
> 
> And then I found this in admin/notes/multi-tty, under known problems:
> 
>         * The single-kboard mode.
> 
> 	  If your multi-tty Emacs session seems to be frozen, you
> 	  probably have a recursive editing session or a pending
> 	  minibuffer prompt (which is a kind of recursive editing) on
> 	  another display.  To unfreeze your session, switch to that
> 	  display and complete the recursive edit, for example by
> 	  pressing C-] ('abort-recursive-edit').
> 
> 	  I am sorry to say that currently there is no way to break
> 	  out of this "single-kboard mode" from a frozen display.  If
> 	  you are unable to switch to the display that locks the
> 	  others (for example because it is on a remote computer),
> 	  then you can use emacsclient to break out of all recursive
> 	  editing sessions:
> 
> 		emacsclient -e '(top-level)'
> 
> 	  Note that this (perhaps) unintuitive behavior is by design.
> 	  Single-kboard mode is required because of an intrinsic Emacs
> 	  limitation that is very hard to eliminate.  (This limitation
> 	  is related to the single-threaded nature of Emacs.)
> 
> 	  I plan to implement better user notification and support for
> 	  breaking out of single-kboard mode from locked displays.
> 
> Also see the long list of things to do in the same file, which makes me
> a bit wary.

Can you explain how the above limitation causes the problem reported
in this bug?  That is, how do child frames trigger the bug?  Because
"normal" frames don't, AFAIU, right?  That is, one could have two or
more client TTY frames on several displays in the same Emacs session,
without having any of them stop being responsive, right?  Also, what
is the role of vertico-posframe in this scenario?

IOW, I don't yet have a clear picture of what happens, although the
limitations you found in that admin file are known to me.  AFAIK, the
single-kboard situation is still with us, search keyboard.c for
"single_kboard".

> @Eli: I think we should invoke a multi-tty expert who can tell if what
> we see here can be kind of expected with the current state of multi-tty or
> not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
> first place.

We don't have such an expert on board, sadly, not for a long while.
We are on our own.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you explain how the above limitation causes the problem reported
> in this bug?  That is, how do child frames trigger the bug?  Because
> "normal" frames don't, AFAIU, right?  That is, one could have two or
> more client TTY frames on several displays in the same Emacs session,
> without having any of them stop being responsive, right?  Also, what
> is the role of vertico-posframe in this scenario?

The hint I see is here

>> 	  If your multi-tty Emacs session seems to be frozen, you
>> 	  probably have a recursive editing session or a pending
>> 	  minibuffer prompt (which is a kind of recursive editing) on
>> 	  another display.

Emacs in our case is kind of frozen, and Vertico is a minibuffer
interaction, where Posframe simply displays the minibuffer differently,
in a child frame.

Not an explanation of course, but it smells a lot like what's happening.
What the real reason behind all this is in the code, and what would need
to be fixed, I can't figure out from notes/multi-tty. Maybe come
combination of open things mentioned there, no idea.

>
> IOW, I don't yet have a clear picture of what happens, although the
> limitations you found in that admin file are known to me.  AFAIK, the
> single-kboard situation is still with us, search keyboard.c for
> "single_kboard".
>
>> @Eli: I think we should invoke a multi-tty expert who can tell if what
>> we see here can be kind of expected with the current state of multi-tty or
>> not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
>> first place.
>
> We don't have such an expert on board, sadly, not for a long while.
> We are on our own.

That's indeed more than suboptimal :-(. 

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 09:46:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you explain how the above limitation causes the problem reported
> > in this bug?  That is, how do child frames trigger the bug?  Because
> > "normal" frames don't, AFAIU, right?  That is, one could have two or
> > more client TTY frames on several displays in the same Emacs session,
> > without having any of them stop being responsive, right?  Also, what
> > is the role of vertico-posframe in this scenario?
> 
> The hint I see is here
> 
> >> 	  If your multi-tty Emacs session seems to be frozen, you
> >> 	  probably have a recursive editing session or a pending
> >> 	  minibuffer prompt (which is a kind of recursive editing) on
> >> 	  another display.
> 
> Emacs in our case is kind of frozen, and Vertico is a minibuffer
> interaction, where Posframe simply displays the minibuffer differently,
> in a child frame.

Yes, but where is that recursive editing in this scenario?

I guess I'd love to see a C backtrace from that situation.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 09:46:48 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Can you explain how the above limitation causes the problem reported
>> > in this bug?  That is, how do child frames trigger the bug?  Because
>> > "normal" frames don't, AFAIU, right?  That is, one could have two or
>> > more client TTY frames on several displays in the same Emacs session,
>> > without having any of them stop being responsive, right?  Also, what
>> > is the role of vertico-posframe in this scenario?
>> 
>> The hint I see is here
>> 
>> >> 	  If your multi-tty Emacs session seems to be frozen, you
>> >> 	  probably have a recursive editing session or a pending
>> >> 	  minibuffer prompt (which is a kind of recursive editing) on
>> >> 	  another display.
>> 
>> Emacs in our case is kind of frozen, and Vertico is a minibuffer
>> interaction, where Posframe simply displays the minibuffer differently,
>> in a child frame.
>
> Yes, but where is that recursive editing in this scenario?

We're switching frames while being in the minibuffer in the other frame.

> I guess I'd love to see a C backtrace from that situation.

Too difficult for me. Emacs is not frozen in the sense that it is
completely stuck somewhere. For example, C-x C-c apparently always
works. C-g seems to work sometimes too, sometimes not. It's more like
the keyboard input doesn't land where it is supposed to. Or something
like that.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 10:04:29 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> >> Date: Fri, 27 Dec 2024 09:46:48 +0100
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Can you explain how the above limitation causes the problem reported
> >> > in this bug?  That is, how do child frames trigger the bug?  Because
> >> > "normal" frames don't, AFAIU, right?  That is, one could have two or
> >> > more client TTY frames on several displays in the same Emacs session,
> >> > without having any of them stop being responsive, right?  Also, what
> >> > is the role of vertico-posframe in this scenario?
> >> 
> >> The hint I see is here
> >> 
> >> >> 	  If your multi-tty Emacs session seems to be frozen, you
> >> >> 	  probably have a recursive editing session or a pending
> >> >> 	  minibuffer prompt (which is a kind of recursive editing) on
> >> >> 	  another display.
> >> 
> >> Emacs in our case is kind of frozen, and Vertico is a minibuffer
> >> interaction, where Posframe simply displays the minibuffer differently,
> >> in a child frame.
> >
> > Yes, but where is that recursive editing in this scenario?
> 
> We're switching frames while being in the minibuffer in the other frame.
> 
> > I guess I'd love to see a C backtrace from that situation.
> 
> Too difficult for me. Emacs is not frozen in the sense that it is
> completely stuck somewhere. For example, C-x C-c apparently always
> works. C-g seems to work sometimes too, sometimes not. It's more like
> the keyboard input doesn't land where it is supposed to. Or something
> like that.

Then why is this a bug?

When a frame is in a minibuffer, it means Emacs asks the user about
something, and in that situation, the user must respond to the prompt,
or exit the minibuffer in some other way.  That's normal in my book.
What am I missing?

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Then why is this a bug?
>
> When a frame is in a minibuffer, it means Emacs asks the user about
> something, and in that situation, the user must respond to the prompt,
> or exit the minibuffer in some other way.  That's normal in my book.
> What am I missing?

Emacs doesn't say anything. The user is just typing into the void, and
it's not easy get out of this state again, except C-x C-c. That's not
normal.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 13:47:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then why is this a bug?
> >
> > When a frame is in a minibuffer, it means Emacs asks the user about
> > something, and in that situation, the user must respond to the prompt,
> > or exit the minibuffer in some other way.  That's normal in my book.
> > What am I missing?
> 
> Emacs doesn't say anything.

It does: on the frame where you are in the minibuffer.

> The user is just typing into the void, and it's not easy get out of
> this state again, except C-x C-c. That's not normal.

My point is that this happens in many other, "simpler" situations.
AFAIK, it isn't limited to TTY frames, either.  So if that's the only
thing that happens here, i.e. some other frame is parked at the
minibuffer prompt, there's nothing new here that we didn't have before
child frames became supported on TTY displays.  Changing that would
need to have per-frame input queues in Emacs, AFAIU, and some way of
multiplexing between them.

But I'm not yet sure this is what we see in this case, which is why I
asked for a C backtrace.  Producing it should be easy: just reproduce
the problem, then attach a debugger and produce the backtrace.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> But I'm not yet sure this is what we see in this case, which is why I
> asked for a C backtrace.  Producing it should be easy: just reproduce
> the problem, then attach a debugger and produce the backtrace.

See below. AFAICS, Emacs is waiting for input, and when we have some,
the wrong things will happen. Please note that this is not a full debug
build.


bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  frame #0: 0x0000000190be51a8 libsystem_kernel.dylib`__pselect + 8
  frame #1: 0x0000000190be5080 libsystem_kernel.dylib`pselect$DARWIN_EXTSN + 64
    frame #2: 0x00000001047181d4 emacs`really_call_select(arg=0x000000016b8d44e0) at thread.c:620:16 [opt]
    frame #3: 0x0000000104718148 emacs`thread_select [inlined] flush_stack_call_func(func=<unavailable>, arg=0x000000016b8d44e0) at lisp.h:4842:3 [opt]
    frame #4: 0x0000000104718138 emacs`thread_select(func=<unavailable>, max_fds=<unavailable>, rfds=<unavailable>, wfds=<unavailable>, efds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at thread.c:652:3 [opt]
    frame #5: 0x000000010473ef04 emacs`ns_select_1(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>, run_loop_only=<unavailable>) at nsterm.m:4873:12 [opt] [artificial]
    frame #6: 0x000000010473ed14 emacs`ns_select(nfds=<unavailable>, readfds=<unavailable>, writefds=<unavailable>, exceptfds=<unavailable>, timeout=<unavailable>, sigmask=<unavailable>) at nsterm.m:5006:10 [opt] [artificial]
    frame #7: 0x00000001046e72c0 emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=<unavailable>, do_display=true, wait_for_cell=<unavailable>, wait_proc=<unavailable>, just_wait_proc=<unavailable>) at process.c:5766:18 [opt]
    frame #8: 0x000000010460d4b4 emacs`read_char [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=0x000000016b8d4f67, end_time=0x0000000000000000) at keyboard.c:0 [opt]
!gud 0::/Users/gerd/emacs/github/cl-packages/src/keyboard.c
    frame #9: 0x000000010460d294 emacs`read_char [inlined] read_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x000000016b8d4c00, used_mouse_menu=0x000000016b8d4f67) at keyboard.c:2336:7 [opt]
    frame #10: 0x000000010460d134 emacs`read_char [inlined] read_decoded_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x000000016b8d4c00, prev_event=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, used_mouse_menu=0x000000016b8d4f67) at keyboard.c:2400:11 [opt]
    frame #11: 0x000000010460d114 emacs`read_char(commandflag=1, map=(struct Lisp_Cons *) $8 = 0x000000010abc8280, prev_event=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, used_mouse_menu=0x000000016b8d4f67, end_time=0x0000000000000000) at keyboard.c:3031:11 [opt]
    frame #12: 0x000000010460992c emacs`read_key_sequence(keybuf=<unavailable>, prompt=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>, disable_text_conversion_p=<unavailable>) at keyboard.c:10762:12 [opt]
    frame #13: 0x0000000104607d9c emacs`command_loop_1 at keyboard.c:1435:15 [opt]
    frame #14: 0x000000010468eeb0 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1330), handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188, hfun=(emacs`cmd_error at keyboard.c:976)) at eval.c:1669:25 [opt]
    frame #15: 0x0000000104607a50 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at keyboard.c:1174:11 [opt]
!gud 1174:11:/Users/gerd/emacs/github/cl-packages/src/keyboard.c
    frame #16: 0x000000010468e504 emacs`internal_catch(tag=(struct Lisp_Symbol *) $13 = 0x0000000104e0f108, func=(emacs`command_loop_2 at keyboard.c:1170), arg=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at eval.c:1348:25 [opt]
    frame #17: 0x000000010460714c emacs`command_loop at keyboard.c:1144:13 [opt]
    frame #18: 0x0000000104607008 emacs`recursive_edit_1 at keyboard.c:760:9 [opt]
    frame #19: 0x000000010463e660 emacs`Fread_from_minibuffer [inlined] read_minibuf(map=<unavailable>, initial=<unavailable>, prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, expflag=<unavailable>, histvar=<unavailable>, histpos=(EMACS_INT) $17 = 0, defalt=<unavailable>, allow_props=<unavailable>, inherit_input_method=<unavailable>) at minibuf.c:905:3 [opt]
!gud 905:3:/Users/gerd/emacs/github/cl-packages/src/minibuf.c
    frame #20: 0x000000010463de28 emacs`Fread_from_minibuffer(prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, initial_contents=<unavailable>, keymap=(struct Lisp_Cons *) $18 = 0x0000000108f15eb0, read=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, hist=<unavailable>, default_value=(struct Lisp_String *) $19 = 0x000000010893a840, inherit_input_method=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0) at minibuf.c:1398:9 [opt]
    frame #21: 0x0000000104691b70 emacs`funcall_subr(subr=0x0000000104da0e70, numargs=7, args=<unavailable>) at eval.c:3237:15 [opt]
    frame #22: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
    frame #23: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
    frame #24: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
    frame #25: 0x000000010468c3f8 emacs`Ffuncall(nargs=9, args=(struct Lisp_Symbol *) $21 = 0x00000002706db770) at eval.c:3157:21 [opt]
    frame #26: 0x0000000104690cac emacs`Fapply(nargs=1, args=(struct Lisp_Symbol *) $25 = 0x0000000244e0e360) at eval.c:2822:24 [opt]
    frame #27: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=1, args=<unavailable>) at eval.c:0 [opt]
    frame #28: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
    frame #29: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
    frame #30: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
    frame #31: 0x000000010468c3f8 emacs`Ffuncall(nargs=10, args=(struct Lisp_Symbol *) $29 = 0x00000002706db9d0) at eval.c:3157:21 [opt]
    frame #32: 0x0000000104690cac emacs`Fapply(nargs=2, args=(struct Lisp_Symbol *) $32 = 0x0000000244e0e2d0) at eval.c:2822:24 [opt]
    frame #33: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=2, args=<unavailable>) at eval.c:0 [opt]
    frame #34: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
    frame #35: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
    frame #36: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
    frame #37: 0x000000010468c3f8 emacs`Ffuncall(nargs=10, args=(struct Lisp_Symbol *) $35 = 0x00000002706dbc30) at eval.c:3157:21 [opt]
    frame #38: 0x0000000104690cac emacs`Fapply(nargs=3, args=(struct Lisp_Symbol *) $39 = 0x0000000244e0e280) at eval.c:2822:24 [opt]
    frame #39: 0x0000000104691ac8 emacs`funcall_subr(subr=0x0000000104da72b0, numargs=3, args=<unavailable>) at eval.c:0 [opt]
    frame #40: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
    frame #41: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
    frame #42: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
!gud 3108:12:/Users/gerd/emacs/github/cl-packages/src/eval.c
    frame #43: 0x000000010468c3f8 emacs`Ffuncall(nargs=<unavailable>, args=(struct Lisp_Symbol *) $42 = 0x00000002706dbef0) at eval.c:3157:21 [opt]
    frame #44: 0x000000010463f3c8 emacs`Fread_buffer(prompt=(struct Lisp_String *) $15 = 0x000000010aba19a8, def=(struct Lisp_String *) $19 = 0x000000010893a840, require_match=(struct Lisp_Symbol *) $45 = 0x00000001084b4d58, predicate=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0) at minibuf.c:0 [opt]
    frame #45: 0x0000000104691bdc emacs`funcall_subr(subr=0x0000000104da0fb0, numargs=3, args=<unavailable>) at eval.c:3231:15 [opt]
    frame #46: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
!gud 828:14:/Users/gerd/emacs/github/cl-packages/src/bytecode.c
    frame #47: 0x00000001046dd188 emacs`Fbyte_code(bytestr=<unavailable>, vector=(struct Lisp_Vector *) $48 = 0x00000001084b4808, maxdepth=(EMACS_INT) $50 = 4) at bytecode.c:325:10 [opt]
    frame #48: 0x000000010468b8e8 emacs`eval_sub(form=(struct Lisp_Cons *) $51 = 0x00000001084b47a8) at eval.c:2661:15 [opt]
    frame #49: 0x0000000104690798 emacs`Feval(form=<unavailable>, lexical=<unavailable>) at eval.c:2514:28 [opt]
    frame #50: 0x0000000104688d84 emacs`Fcall_interactively(function=<unavailable>, record_flag=(struct Lisp_Symbol *) $4 = 0x0000000104e060e0, keys=(struct Lisp_Vector *) $52 = 0x000000010ab9ee88) at callint.c:325:15 [opt]
    frame #51: 0x0000000104691c1c emacs`funcall_subr(subr=0x0000000104da68f0, numargs=3, args=<unavailable>) at eval.c:3229:15 [opt]
    frame #52: 0x00000001046de5f0 emacs`exec_byte_code(fun=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:828:14 [opt]
    frame #53: 0x0000000104691d0c emacs`funcall_lambda(fun=<unavailable>, nargs=<unavailable>, arg_vector=<unavailable>) at eval.c:3316:9 [opt] [artificial]
    frame #54: 0x0000000104691a40 emacs`funcall_general(fun=<unavailable>, numargs=<unavailable>, args=<unavailable>) at eval.c:3108:12 [opt] [artificial]
    frame #55: 0x000000010468c3f8 emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $54 = 0x00000002706dc610) at eval.c:3157:21 [opt]
    frame #56: 0x0000000104607fb0 emacs`command_loop_1 at keyboard.c:1556:13 [opt]
    frame #57: 0x000000010468eeb0 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1330), handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188, hfun=(emacs`cmd_error at keyboard.c:976)) at eval.c:1669:25 [opt]
    frame #58: 0x0000000104607a50 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at keyboard.c:1174:11 [opt]
    frame #59: 0x000000010468e504 emacs`internal_catch(tag=(struct Lisp_Symbol *) $58 = 0x0000000104e1aba0, func=(emacs`command_loop_2 at keyboard.c:1170), arg=(struct Lisp_Symbol *) $10 = 0x0000000104e06188) at eval.c:1348:25 [opt]
    frame #60: 0x00000001046071c8 emacs`command_loop at keyboard.c:1152:2 [opt]
!gud 1152:2:/Users/gerd/emacs/github/cl-packages/src/keyboard.c
    frame #61: 0x0000000104607008 emacs`recursive_edit_1 at keyboard.c:760:9 [opt]
    frame #62: 0x000000010460740c emacs`Frecursive_edit at keyboard.c:843:3 [opt]
    frame #63: 0x0000000104606134 emacs`main(argc=<unavailable>, argv=0x000000016b8d6c30) at emacs.c:2655:3 [opt]
  frame #64: 0x00000001908a0274 dyld`start + 2840
(lldb) 

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 14:17:11 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But I'm not yet sure this is what we see in this case, which is why I
> > asked for a C backtrace.  Producing it should be easy: just reproduce
> > the problem, then attach a debugger and produce the backtrace.
> 
> See below. AFAICS, Emacs is waiting for input, and when we have some,
> the wrong things will happen. Please note that this is not a full debug
> build.

Thanks.  This lacks the equivalent of "xbacktrace", so a bit hard to
interpret, but I see read-from-minibuffer which called recursive-edit.

What is the recipe for this, starting from "emacs -Q", please?  Can
this be reproduced without posframe?

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 14:17:11 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > But I'm not yet sure this is what we see in this case, which is why I
>> > asked for a C backtrace.  Producing it should be easy: just reproduce
>> > the problem, then attach a debugger and produce the backtrace.
>> 
>> See below. AFAICS, Emacs is waiting for input, and when we have some,
>> the wrong things will happen. Please note that this is not a full debug
>> build.
>
> Thanks.  This lacks the equivalent of "xbacktrace", so a bit hard to
> interpret, but I see read-from-minibuffer which called recursive-edit.
>
> What is the recipe for this, starting from "emacs -Q", please?  

The one the OP gave is good.

> Can this be reproduced without posframe?

No idea.

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Len Trigg]

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

(Sorry Eli for the dup email, I initially used Reply rather than Reply-All)

On Sat, 28 Dec 2024 at 02:02, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> > Date: Fri, 27 Dec 2024 13:47:09 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > Then why is this a bug?
> > >
> > > When a frame is in a minibuffer, it means Emacs asks the user about
> > > something, and in that situation, the user must respond to the prompt,
> > > or exit the minibuffer in some other way.  That's normal in my book.
> > > What am I missing?
> >
> > Emacs doesn't say anything.
>
> It does: on the frame where you are in the minibuffer.
>

Hmmm, the repro scenario I gave doesn't involve either emacs client being
still in the minibuffer AFAIK - the "working" client is just in a regular
buffer (e.g. having been chosen via C-x b and selected), and the "hung"
client is, well, hung.

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

bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

[Len Trigg]

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

On Sat, 28 Dec 2024 at 07:13, Len Trigg <lenbok@gmail.com> wrote:

> Hmmm, the repro scenario I gave doesn't involve either emacs client being
> still in the minibuffer AFAIK - the "working" client is just in a regular
> buffer (e.g. having been chosen via C-x b and selected), and the "hung"
> client is, well, hung.
>

To elaborate my steps:
emacs -nw --init-directory=~/emacs-test  (the first time will result in
packages being installed by elpaca)
(in another terminal) emacsclient -nw
Then invoke the child frame pop up: (e.g. C-x b and C-n to select
*Messages* and RET). Now we're no longer in a minibuffer.
Switch back to the original emacs
Invoke the child frame pop up (e.g. C-x b and C-n to select *Messages* and
RET). Now we're no longer in a minibuffer.
Swap to the other terminal, and note that the client is "hung".

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