bug#55726: 28.1; emacs becomes unresponsive to input

[Eli Zaretskii <eliz@gnu.org>]

> Cc: ejb@ql.org
> Date: Mon, 30 May 2022 08:58:26 -0400
> From: "Jay Berkenbilt" <ejb@ql.org>
> 
> My hunch is that is a race condition that gets triggered when I am
> typing as buffers, windows, or frames are being rearranged in some way.
> I have been using gnu emacs since 1987 and move around in it very fast.
> A lot of my emacs usage is somewhat beneath the level of conscious
> awareness. Typically when this happens, I'm in the midst of some
> operation and don't notice for a few seconds that emacs is not
> responsive, so there's no way for me to be sure exactly what I was doing
> at the moment that it became unresponsive. Just now when this happened,
> I had taken two sections of a buffer and copied them into two temporary
> buffers, then run M-x ediff-buffers on those buffers. When I got what I
> wanted, I exited the ediff session, killed the two buffers one after the
> other, did C-x 1 to make the original file the single buffer in its
> window (and frame), and started typing in and navigating around the
> buffer only to see that emacs had become unresponsive. All this
> manipulation probably happened within one or two seconds.
> (q y C-x k C-x k C-x 1 typie-typie-typie)
> 
> My emacs is built from source using default configure options, so I was
> able to attach my running emacs process in gdb and get a stack trace.
> Here is the stack trace:
> 
> #0  pselect64_syscall (sigmask=<optimized out>, timeout=<optimized out>, exceptfds=0x0, writefds=0x7fff68e9c1f0, readfds=0x7fff68e9c170, nfds=15) at ../sysdeps/unix/sysv/linux/pselect.c:34
> #1  __pselect (nfds=15, readfds=0x7fff68e9c170, writefds=0x7fff68e9c1f0, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:56
> #2  0x000055c1bad0f035 in really_call_select (arg=0x7fff68e9c060) at thread.c:596
> #3  0x000055c1bad0fe73 in flush_stack_call_func (arg=0x7fff68e9c060, func=0x55c1bad0efc0 <really_call_select>) at /home/ejb/tmp/net/emacs-28.1/src/lisp.h:3834
> #4  thread_select (func=<optimized out>, max_fds=max_fds@entry=15, rfds=rfds@entry=0x7fff68e9c170, wfds=wfds@entry=0x7fff68e9c1f0, efds=efds@entry=0x0, timeout=timeout@entry=0x7fff68e9c7b0, sigmask=0x0) at thread.c:628
> #5  0x000055c1bad2d8d1 in xg_select (fds_lim=15, rfds=rfds@entry=0x7fff68e9c8c0, wfds=wfds@entry=0x7fff68e9c940, efds=efds@entry=0x0, timeout=timeout@entry=0x7fff68e9c7b0, sigmask=sigmask@entry=0x0) at xgselect.c:147
> #6  0x000055c1bacecb15 in wait_reading_process_output (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5591
> #7  0x000055c1bac2de6c in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7fff68e9d14b, kbp=<synthetic pointer>) at keyboard.c:3926
> #8  read_event_from_main_queue (used_mouse_menu=0x7fff68e9d14b, local_getcjmp=0x7fff68e9cd50, end_time=0x0) at keyboard.c:2198
> #9  read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>, prev_event=<optimized out>, local_getcjmp=<optimized out>, end_time=<optimized out>) at keyboard.c:2262
> #10 read_char (commandflag=1, map=0x55c1bc5e5ae3, prev_event=0x0, used_mouse_menu=0x7fff68e9d14b, end_time=0x0) at keyboard.c:2892
> #11 0x000055c1bac304d4 in read_key_sequence (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9635

This says that Emacs's main thread is just waiting for input, either
from the keyboard or from any other sources, like the window-system or
subprocesses.

If this session is still alive under GDB, please type this command:

  (gdb) thread apply all bt

and show the output -- it will tell us what the other threads are
doing.  If you already killed that session, then do the above next
time it happens.

It is also important to know whether Emacs is stuck or inflooping.  Do
you happen to know if it was using the CPU while in this state?  The
strategy to dig into the problem depends on whether Emacs hangs (which
might mean some kind of deadlock), or infloops in some code.

> Load-path shadows:
> /home/ejb/elisp/startup hides /usr/local/emacs-28.1/share/emacs/28.1/lisp/startup

Did you build your own Emacs, and if so, is it possible that this
startup.el, which shadows the standard one, was dumped into the
executable?  If so, it could be part of the puzzle.