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

[Eli Zaretskii <eliz@gnu.org>]

> 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?