bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames

bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames

[Phil Sainty]

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

I've recently switched my main instance of Emacs to 30.0 (firstly
30.0.93, and now the HEAD of the emacs-30 branch), and I've been
experiencing frequent hangs (with the CPU core spinning at 100% usage)
when creating new frames.

More specifically: when creating frames using a system I use with my
window manager when I want to interactively select a thing in a pop-up
Emacs frame.  (I've tried to replicate this with simply "C-x 5 2" but
didn't manage to do so thus far.)

If I spam a terminal with a large number of "kill -USR2 <pid>" commands
for the spinning Emacs process ID, then I'll get control back.

I'm experiencing this (inconsistently, but quite often) with using a
keybinding for my window manager (XMonad), which runs a command like:

  emacsclient --eval "(my-x-paste-example $(xdotool getactivewindow))"

With that command being something like:

  (defun my-x-paste-example (wid)
     (interactive)
     (my-x-paste #'my-example wid "*Example*" "Testing"))

  (defun my-example ()
    (interactive)
    (gui-backend-set-selection
     'CLIPBOARD (completing-read "Choose: " '(one two three))))

I've attached the definition of `my-x-paste' to this report.  It
creates a small floating frame for the interaction, and afterwards it
runs xdotool again to paste the clipboard contents into the X window
obtained by "xdotool getactivewindow", but I think the xdotool aspect
shouldn't be a factor, as it never gets that far -- Emacs creates the
frame and then immediately hangs before I can interact with it at all.
Perhaps the frame parameters used in that function are relevant,
though.

I've recompiled Emacs for debugging and run it under gdb, and have
reproduced a hang, so I have also attached some backtraces from gdb
(more than one because they're variable).  In each case I used
"kill -TSTP <PID>" to stop Emacs spinning and drop to the gdb prompt,
and then the "backtrace" command.  I then had to "continue" multiple
times before Emacs started running/spinning again, after which I
repeated the process.

(I also tried "xbacktrace" but that just said "Undefined command:
"xbacktrace".  Try "help".", and I'm afraid that I only just saw the
"bt full" recommendation in the report-emacs-bug template -- the
etc/DEBUG file doesn't actually mention that command -- and I've not
been able to reproduce the issue in the interim to try that one, so
I'm sending this as-is for now.)

The function I'm calling in lisp does a `completing-read', and I can
see Fread_from_minibuffer in the backtrace, so I *guess* it's getting
that far after creating the frame; but I'm not sure if that's a factor
as (I think) I've also seen this with a pop-up notification frame
I use for appt.el notifications -- and that one doesn't prompt me at
all (but it's creating frames in a fairly similar way).

I can't replicate this at will, but it happens often enough that I
*should* be able to recreate it again sometime soon, so let me know
if you want me to try other things (but note that I'm not familiar
with gdb and debugging C code, so step-by-step instructions will be
helpful for that).


-Phil




In GNU Emacs 30.0.93 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo
  version 1.16.0, Xaw scroll bars) of 2025-01-09 built on phil-lp
Repository revision: 01464fc882dbb56d4271fbb89b7b847e8374d39c
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101004
System Description: Ubuntu 22.04.5 LTS

Configured using:
  'configure --prefix=/home/phil/emacs/30.x/usr/local
  --without-native-compilation --with-x-toolkit=lucid --without-sound
  '--program-transform-name=s/^ctags$/ctags_emacs/'
  --enable-checking=yes,glyphs --enable-check-lisp-object-type
  'CFLAGS=-O0 -g3''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM
XPM LUCID ZLIB

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

Major mode: IBuffer

Minor modes in effect:
   text-scale-mode: t
   hexl-follow-ascii: t
   magit-wip-initial-backup-mode: t
   magit-wip-before-change-mode: t
   magit-wip-after-apply-mode: t
   magit-wip-after-save-mode: t
   magit-wip-mode: t
   global-git-commit-mode: t
   magit-auto-revert-mode: t
   catalyst-directory-event-icalendar-sync-mode: t
   minibuffer-line-mode: t
   global-edit-server-edit-mode: t
   savehist-mode: t
   global-anzu-mode: t
   anzu-mode: t
   my-contextual-help-mode: t
   global-so-long-mode: t
   server-mode: t
   global-visible-mark-mode: t
   visible-mark-mode: t
   repeat-mode: t
   display-battery-mode: t
   my-visible-bell-mode: t
   global-display-fill-column-indicator-mode: t
   minibuffer-depth-indicate-mode: t
   which-key-mode: t
   winner-mode: t
   keep-buffers-mode: t
   global-subword-mode: t
   subword-mode: t
   global-hl-line-mode: t
   display-time-mode: t
   recentf-mode: t
   global-atomic-chrome-edit-mode: t
   my-global-keys-local-minor-mode: t
   my-keys-local-minor-mode: t
   windmove-mode: t
   url-handler-mode: t
   auto-compile-on-load-mode: t
   auto-compile-on-save-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tab-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   minibuffer-regexp-mode: t
   buffer-read-only: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t

Load-path shadows:
/home/phil/.emacs.d/el-get/scratch/el-get hides 
/home/phil/.emacs.d/el-get/el-get/el-get
/home/phil/.emacs.d/el-get/avy/avy hides 
/home/phil/.emacs.d/elpa/avy-0.5.0/avy
/home/phil/.emacs.d/el-get/dash/dash hides 
/home/phil/.emacs.d/elpa/dash-2.19.1/dash
/home/phil/.emacs.d/el-get/iedit/iedit hides 
/home/phil/.emacs.d/elpa/iedit-0.9.9.9.9/iedit
/home/phil/.emacs.d/my-lisp/psysh hides 
/home/phil/.emacs.d/elpa/psysh-0.4.9/psysh
/home/phil/.emacs.d/elpa/transient-0.7.9/transient hides 
/home/phil/emacs/30.x/usr/local/share/emacs/30.0.93/lisp/transient
/home/phil/.emacs.d/el-get/which-key/which-key hides 
/home/phil/emacs/30.x/usr/local/share/emacs/30.0.93/lisp/which-key

Features:
(shadow sort ecomplete mail-extr emacsbug ibuf-ext ibuffer
ibuffer-loaddefs dired-aux face-remap pulse color help-fns xref project
hi-lock noutline outline find-func totp hexl executable magit-wip
magit-log which-func imenu magit-diff smerge-mode diff git-commit
log-edit message sendmail yank-media rfc822 mml mml-sec gnus-util
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader pcvs-util
add-log magit-core magit-autorevert autorevert filenotify magit-margin
magit-transient magit-process magit-mode transient edmacro compat
magit-git magit-section magit-utils crm dash mail-utils gnutls
network-stream url-cache epa-file epa epg rfc6068 epg-config view
holidays holiday-loaddefs cal-julian lunar solar cal-dst vc-git
diff-mode track-changes vc-dispatcher autoinsert bug-reference appt
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs lexbind-mode
hl-sexp fic-mode elide-head idle-highlight-mode catalyst-directory
vtable mule-util url-http url-auth mail-parse rfc2231 rfc2047 rfc2045
mm-util ietf-drums mail-prsvr url-gw nsm puny goto-addr sockit tabify
minibuffer-line edit-server my-org my-projects my-session savehist
desktop frameset my-theme zenburn-theme my-mail my-libraries sudo anzu
my-version-control my-text my-programming so-long my-rectangles rect
my-utilities with-editor server browse-kill-ring derived term disp-table
shell pcomplete ehelp my-configuration visible-mark cus-edit pp cus-load
dired-details dired-x repeat highlight-parentheses format-spec battery
delight delsel ffap thingatpt display-fill-column-indicator mb-depth
which-key pcase easy-mmode winner keep-buffers cap-words superword
subword hl-line time recentf tree-widget wid-edit atomic-chrome
websocket bindat let-alist my-whitespace ws-trim my-externals .loaddefs
rainbow-mode notify dbus xml mo-git-blame cl iedit el-get cl-extra
help-mode autoload loaddefs-gen radix-tree lisp-mnt dired dired-loaddefs
my-holidays my-local kmacro my-mahara grep tks generic-x catalyst
redshift-indent my-keybindings framemove advice windmove my-startup-log
trace cl-print time-date adaptive-wrap-autoloads dape-autoloads
docker-autoloads dockerfile-mode-autoloads eat-autoloads
eldoc-box-autoloads elfeed-autoloads haskell-mode-autoloads
helpful-autoloads elisp-refs-autoloads f-autoloads iedit-autoloads rx
modus-themes-autoloads psysh-autoloads rfc-mode-autoloads s-autoloads
markdown-mode-autoloads tablist-autoloads info transient-autoloads
visual-fill-autoloads websocket-autoloads wtf-autoloads xr-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source ...)

Memory information:
((conses 16 342345 195376) (symbols 48 38691 4)
  (strings 32 146239 28849) (string-bytes 1 3881004) (vectors 16 64057)
  (vector-slots 8 1530248 160628) (floats 8 907 8658)
  (intervals 56 9801 2166) (buffers 992 27))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: my-x-paste.el --]
[-- Type: text/x-lisp; name=my-x-paste.el, Size: 3470 bytes --]

(defun my-x-paste (command wid &optional bufname header text)
  "Run COMMAND and paste the result into the original X window.

\(For use with programs where \"C-v\" is paste.)

The value returned from COMMAND will be set in the system clipboard,
and then the key \"C-v\" will be performed in the original X window.

The pop-up frame will initially display a temporary buffer named
BUFNAME which is displaying the `header-line-format' HEADER, and
buffer contents TEXT.  You can use these to give the user context
for the interaction.

Requires that \"xdotool\" is installed on your system.  E.g.:

 sudo apt-get install xdotool

To use, trigger the following command via your window manager:

 emacsclient --eval \"(my-x-paste-COMMAND $(xdotool getactivewindow))\"

With \(my-x-paste-COMMAND wid) being a wrapper for calling `my-x-paste'.

Example:

 \(defun my-x-paste-totp (wid)
   \"Paste `totp-as-clipboard' into X window WID (see `my-x-paste').\"
   (interactive)
   (my-x-paste #\\='totp-as-clipboard wid \"*TOTP\"
               \"Time-based One-time Password (TOTP)\"))

XMonad key binding (mod-T) for xmonad.hs:

 , ((modMask .|. shiftMask, xK_t), spawn \"emacsclient --eval \\
 \\\"(my-x-paste-totp $(xdotool getactivewindow))\\\"\")

Also for XMonad, include the following in your manageHook to make the
pop-up frame float over the other windows rather than being tiled:

 appName =? \"EmacsXPaste\" --> doFloat"
  (interactive)
  (with-temp-buffer
    (when bufname
      (rename-buffer bufname :unique))
    (when header
      (setq-local header-line-format header))
    (when text
      (insert text))
    (let* ((buf (current-buffer))
           (width 80)
           (height (max window-safe-min-height
                        (count-lines (point-min) (point-max))))
           (pxwidth (+ 3 (* width (default-font-width))))
           (pxheight (+ 3 (* height (default-font-height))))
           (fparams `((my-x-paste . t)
                      (name . "EmacsXPaste")
                      (fullscreen . nil)
                      (width . ,width)
                      (height . ,height)
                      (left . ,(- (/ (display-pixel-width) 2) (/ pxwidth 2)))
                      (top . ,(- (/ (display-pixel-height) 2) (/ pxheight 2)))
                      (menu-bar-lines . 0)
                      (tool-bar-lines . 0)
                      (auto-raise . t))))
      (select-frame (make-frame fparams))
      (pop-to-buffer buf)
      (delete-other-windows)
      (unwind-protect
          (let ((value (call-interactively command)))
            (and value
                 (integerp wid)
                 (gui-backend-set-selection 'CLIPBOARD value)
                 (call-process "xdotool" nil nil nil
                               "key"
                               "--clearmodifiers"
                               "--window" (number-to-string wid)
                               "ctrl+v")
                 t))
        ;; We need to give the target window time to talk to the Emacs frame to
        ;; extract the clipboard text before the frame is deleted.  This should
        ;; only take a moment; but as we don't know for sure how long we need, we
        ;; make the frame invisible and then sleep for a full second.  Note that
        ;; we need to redisplay to activate the visibility change.
        (set-frame-parameter (selected-frame) 'visibility nil)
        (redisplay)
        (sleep-for 1)
        (delete-frame)))))

[-- Attachment #3: backtrace1.txt.gz --]
[-- Type: application/x-gzip, Size: 2474 bytes --]

[-- Attachment #4: backtrace2.txt.gz --]
[-- Type: application/x-gzip, Size: 2966 bytes --]

[-- Attachment #5: backtrace3.txt.gz --]
[-- Type: application/x-gzip, Size: 4798 bytes --]

[-- Attachment #6: backtrace4.txt.gz --]
[-- Type: application/x-gzip, Size: 2797 bytes --]

bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames

[Eli Zaretskii]

> Date: Fri, 10 Jan 2025 01:09:20 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> I've recently switched my main instance of Emacs to 30.0 (firstly
> 30.0.93, and now the HEAD of the emacs-30 branch), and I've been
> experiencing frequent hangs (with the CPU core spinning at 100% usage)
> when creating new frames.
> 
> More specifically: when creating frames using a system I use with my
> window manager when I want to interactively select a thing in a pop-up
> Emacs frame.  (I've tried to replicate this with simply "C-x 5 2" but
> didn't manage to do so thus far.)
> 
> If I spam a terminal with a large number of "kill -USR2 <pid>" commands
> for the spinning Emacs process ID, then I'll get control back.
> 
> I'm experiencing this (inconsistently, but quite often) with using a
> keybinding for my window manager (XMonad), which runs a command like:
> 
>   emacsclient --eval "(my-x-paste-example $(xdotool getactivewindow))"
> 
> With that command being something like:
> 
>   (defun my-x-paste-example (wid)
>      (interactive)
>      (my-x-paste #'my-example wid "*Example*" "Testing"))
> 
>   (defun my-example ()
>     (interactive)
>     (gui-backend-set-selection
>      'CLIPBOARD (completing-read "Choose: " '(one two three))))
> 
> I've attached the definition of `my-x-paste' to this report.  It
> creates a small floating frame for the interaction, and afterwards it
> runs xdotool again to paste the clipboard contents into the X window
> obtained by "xdotool getactivewindow", but I think the xdotool aspect
> shouldn't be a factor, as it never gets that far -- Emacs creates the
> frame and then immediately hangs before I can interact with it at all.
> Perhaps the frame parameters used in that function are relevant,
> though.
> 
> I've recompiled Emacs for debugging and run it under gdb, and have
> reproduced a hang, so I have also attached some backtraces from gdb
> (more than one because they're variable).  In each case I used
> "kill -TSTP <PID>" to stop Emacs spinning and drop to the gdb prompt,
> and then the "backtrace" command.  I then had to "continue" multiple
> times before Emacs started running/spinning again, after which I
> repeated the process.
> 
> (I also tried "xbacktrace" but that just said "Undefined command:
> "xbacktrace".  Try "help".", and I'm afraid that I only just saw the
> "bt full" recommendation in the report-emacs-bug template -- the
> etc/DEBUG file doesn't actually mention that command -- and I've not
> been able to reproduce the issue in the interim to try that one, so
> I'm sending this as-is for now.)
> 
> The function I'm calling in lisp does a `completing-read', and I can
> see Fread_from_minibuffer in the backtrace, so I *guess* it's getting
> that far after creating the frame; but I'm not sure if that's a factor
> as (I think) I've also seen this with a pop-up notification frame
> I use for appt.el notifications -- and that one doesn't prompt me at
> all (but it's creating frames in a fairly similar way).
> 
> I can't replicate this at will, but it happens often enough that I
> *should* be able to recreate it again sometime soon, so let me know
> if you want me to try other things (but note that I'm not familiar
> with gdb and debugging C code, so step-by-step instructions will be
> helpful for that).

Run Emacs normally, not from GD, and when it hangs attach GDB to it
and say

  (gdb) thread apply all bt

Then post here everything GDB produces.  (It is best to run GDB from
the src directory of the Emacs source tree, where it will read the
.gdbinit file which helps displaying Lisp objects.)

If we don't see from the first backtrace you produce what is the
problem, then do the above several times, so we could see some pattern
of where it hangs.

Btw, by "hangs" you mean it is stuck doing nothing, right?  It doesn't
use 100% of some CPU execution unit (that would be "infloops", not
"hangs"), right?

bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames

[Phil Sainty]

Well I don't know what the connection is, but I've now realised that
this seems to happen only when my *mu4e-headers* buffer (for the mu4e
email client) is visible.  As soon as I opened that I could reproduce
the problem again, and it seems to be a consistent trigger.

I'm using the version of mu4e which is packaged for Ubuntu 22.04:

Package: mu4e
Source: maildir-utils
Version: 1.4.15-1

That version is a few years old -- https://www.djcbsoftware.nl/code/mu/
says mu/mu4e 1.4 was released on 2020-04-18 -- but I'm using that
version to align with the packaged version of mu itself (the Ubuntu
package name for that one is "maildir-utils"), so I can't trivially
switch to a newer release.

On 2025-01-10 02:12, Eli Zaretskii wrote:
> Btw, by "hangs" you mean it is stuck doing nothing, right?  It
> doesn't use 100% of some CPU execution unit (that would be
> "infloops", not "hangs"), right?

No, I did mean an infinite loop (the "hang" was that this causes
the user interface to freeze up unless I signal the process).


> Run Emacs normally, not from GD, and when it hangs attach GDB to it
> and say
> 
>   (gdb) thread apply all bt
> 
> Then post here everything GDB produces.

Ok.  It's too late to continue with this right now, so I'll follow
this up later...


-Phil

bug#75461: 30.0.93; Frequent (but inconsistent) hangs when creating frames

[Eli Zaretskii]

> Date: Fri, 10 Jan 2025 02:25:51 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: 75461@debbugs.gnu.org
> 
> On 2025-01-10 02:12, Eli Zaretskii wrote:
> > Btw, by "hangs" you mean it is stuck doing nothing, right?  It
> > doesn't use 100% of some CPU execution unit (that would be
> > "infloops", not "hangs"), right?
> 
> No, I did mean an infinite loop (the "hang" was that this causes
> the user interface to freeze up unless I signal the process).

If it's an infloop, please follow the steps described in etc/DEBUG
under "If the symptom of the bug is that Emacs fails to respond".

> > Run Emacs normally, not from GD, and when it hangs attach GDB to it
                                 ^^
That was meant to be "GDB", of course.

Thanks.