bug#55726: 28.1; emacs becomes unresponsive to input

bug#55726: 28.1; emacs becomes unresponsive to input

[Jay Berkenbilt]

X-Debbugs-CC: ejb@ql.org

I must apologize in advance for what is going to be a vague bug report.
Please understand that I am a developer and an advanced emacs user, and
with some prompting, I'm sure I will be able to provide more helpful
information. I ask you to bear with me and help me help you figure out
what's going on.

Problem description: I'm typing along, and all of a sudden, emacs
becomes completely unresponsive to mouse and keyboard events. It still
refreshes properly. I haven't been able to find any way out of this
other than to kill the process.

At this time, I haven't been able to discern any pattern of when emacs
gets into this state, so I don't have a recipe to reproduce it from
emacs -Q or from my environment. I have been unable to reproduce it on
demand. I have been running emacs 28.1 since a day or two after it was
released, and I have had this happen maybe half a dozen times since
then. I am in emacs all day most days, so this happens infrequently.

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
#12 0x000055c1bac31e9c in command_loop_1 () at keyboard.c:1392
#13 0x000055c1baca1a47 in internal_condition_case (bfun=bfun@entry=0x55c1bac31ca0 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55c1bac28490 <cmd_error>) at eval.c:1450
#14 0x000055c1bac224be in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1133
#15 0x000055c1baca1989 in internal_catch (tag=tag@entry=0xe850, func=func@entry=0x55c1bac22490 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1181
#16 0x000055c1bac22459 in command_loop () at keyboard.c:1111
#17 0x000055c1bac28080 in recursive_edit_1 () at keyboard.c:720
#18 0x000055c1bac283d9 in Frecursive_edit () at keyboard.c:803
#19 0x000055c1bab37054 in main (argc=1, argv=<optimized out>) at emacs.c:2354

I'm hoping you can give me some advice as to how to help track this
down including other information I can capture next time, possible
commands I can run in gdb to get it unstuck, etc.

The information below was generated from the emacs I used to create this
bug report, not the one that crashed (obviously). They are the same
emacs executable with my same emacs lisp environment, but the runtime
information will be different. I had not been in emacs very long today
when this happened, and I had just a handful of C++ source files loaded
up and some text files. I had run M-x compile a few times and M-x ediff
a few times.

-----


In GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0)
 of 2022-04-23 built on soup
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Ubuntu 22.04 LTS

Configured using:
 'configure --prefix=/usr/local/emacs-28.1'

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

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

Major mode: Text

Minor modes in effect:
  pyvenv-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill

Load-path shadows:
/home/ejb/elisp/startup hides /usr/local/emacs-28.1/share/emacs/28.1/lisp/startup
/usr/local/emacs-28.1/share/emacs/28.1/lisp/net/sasl hides /usr/share/emacs/site-lisp/flim/sasl

Features:
(shadow sort flyspell ispell mail-extr emacsbug sendmail yasnippet
highlight-indentation flymake-proc flymake warnings thingatpt
company-capf company pcase help-fns radix-tree elpy edmacro kmacro
elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util elpy-shell elpy-profile elpy-django s
elpy-refactor python tramp-sh tramp tramp-loaddefs trampver
tramp-integration tramp-compat shell pcomplete parse-time iso8601
ls-lisp format-spec ido grep files-x etags fileloop generator xref
project cus-edit pp wid-edit cl-extra help-mode use-package-ensure
use-package-core clang-format xml w3m-load vc-svn vc vc-dispatcher qmime
qmime-compose qmime-view filecache server compile-eslint rx compile
ange-ftp comint ansi-color ring message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader cc-styles cc-align
cc-engine cc-vars cc-defs jka-compr cus-load advice info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd 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 cl-generic 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 simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 173419 10743)
 (symbols 48 19029 1)
 (strings 32 58491 3447)
 (string-bytes 1 1986291)
 (vectors 16 31087)
 (vector-slots 8 343387 21026)
 (floats 8 88 47)
 (intervals 56 266 0)
 (buffers 992 11))

bug#55726: 28.1; emacs becomes unresponsive to input

[Eli Zaretskii]

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

bug#55726: 28.1; emacs becomes unresponsive to input

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jay Berkenbilt [2022-05-30 08:58 -0400] wrote:

> Problem description: I'm typing along, and all of a sudden, emacs
> becomes completely unresponsive to mouse and keyboard events. It still
> refreshes properly. I haven't been able to find any way out of this
> other than to kill the process.

Have you tried attaching to the frozen Emacs instance from a terminal?

> 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
> #12 0x000055c1bac31e9c in command_loop_1 () at keyboard.c:1392
> #13 0x000055c1baca1a47 in internal_condition_case (bfun=bfun@entry=0x55c1bac31ca0 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55c1bac28490 <cmd_error>) at eval.c:1450
> #14 0x000055c1bac224be in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1133
> #15 0x000055c1baca1989 in internal_catch (tag=tag@entry=0xe850, func=func@entry=0x55c1bac22490 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1181
> #16 0x000055c1bac22459 in command_loop () at keyboard.c:1111
> #17 0x000055c1bac28080 in recursive_edit_1 () at keyboard.c:720
> #18 0x000055c1bac283d9 in Frecursive_edit () at keyboard.c:803
> #19 0x000055c1bab37054 in main (argc=1, argv=<optimized out>) at emacs.c:2354

I ask about attaching from the terminal because your description and
stacktrace remind me of my experience in https://bugs.gnu.org/48629,
which I have run into once or twice in the last few months of infrequent
Emacs usage.

HTH,

-- 
Basil

bug#55726: 28.1; emacs becomes unresponsive to input

[Jay Berkenbilt]

On Mon, May 30, 2022, at 10:36 AM, Basil L. Contovounesios wrote:
> Jay Berkenbilt [2022-05-30 08:58 -0400] wrote:
> 
> > Problem description: I'm typing along, and all of a sudden, emacs
> > becomes completely unresponsive to mouse and keyboard events. It still
> > refreshes properly. I haven't been able to find any way out of this
> > other than to kill the process.
> 
> Have you tried attaching to the frozen Emacs instance from a terminal?
> 
> I ask about attaching from the terminal because your description and
> stacktrace remind me of my experience in https://bugs.gnu.org/48629,
> which I have run into once or twice in the last few months of infrequent
> Emacs usage.
> 
> HTH,
> 
> -- 
> Basil
> 

I haven't tried that. That's a great idea for a potential workaround
while we're tracking this down. I'll try it next time.

bug#55726: 28.1; emacs becomes unresponsive to input

[Jay Berkenbilt]

oops -- accidentally left bug address off my previous reply...

On Mon, May 30, 2022, at 9:57 AM, Eli Zaretskii wrote:
> > Cc: ejb@ql.org
> > Date: Mon, 30 May 2022 08:58:26 -0400
> > From: "Jay Berkenbilt" <ejb@ql.org>
> > 
>> . . .
> > 
> > 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:
> > 
> > . . .
> 
> 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.

I will do it next time it happens. Thanks.

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

I don't think the CPU was spinning, but I can't guarantee. I will also
check this the next time it happens.

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

I don't think it is. My elisp/startup.el defines a function called
"qstartup". If I run emacs -Q, (fboundp 'qstartup) is nil, and if I
run with my environment, (fboundp qstartup) is t. Anyway, I don't
think there's anything in the build process that would read my .emacs,
and my .emacs has been loading ~/elisp/startup.el for decades. I'm not
aware of this ever having caused a problem, but I could consider
renaming the file. I'll wait to make that change until I have a
reliable way to reproduce the problem. Thanks -- this is definitely
something to account for.

bug#55726: 28.1; emacs becomes unresponsive to input

[dick]

It's happened to me twice in the last two weeks, both times in a
recursive edit within the minibuffer.

Your witnessing the same with emacs-28.1 conflicts with my impulse to
blame changes within the last month.

bug#55726: 28.1; emacs becomes unresponsive to input

[Jay Berkenbilt]

The issue finally happened again. I was exiting M-x ediff-revision. I
think ediff definitely seems to increase the odds.

> On Mon, May 30, 2022, at 9:57 AM, Eli Zaretskii wrote:
> > > Cc: ejb@ql.org
> > > Date: Mon, 30 May 2022 08:58:26 -0400
> > > From: "Jay Berkenbilt" <ejb@ql.org>
> > >
> >> . . .
> > >
> > > 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:
> > >
> > > . . .
> >
> > 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.

Attaching to process 3403
[New LWP 3410]
[New LWP 3503]
[New LWP 3621]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pselect64_syscall (sigmask=<optimized out>, timeout=<optimized out>, exceptfds=0x0, writefds=0x7ffdfac20990, readfds=0x7ffdfac20910, nfds=19) at ../sysdeps/unix/sysv/linux/pselect.c:34
34	../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.

Thread 4 (Thread 0x7f7bf0917640 (LWP 3621) "dconf worker"):
#0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d85854c0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f7bf7b753c3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f7bf0a3133d in  () at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
#4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7f7bf12bd640 (LWP 3503) "gdbus"):
#0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d843aea0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f7bf7b77293 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f7bf7dd2c1a in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x7f7bf1b36640 (LWP 3410) "gmain"):
#0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d8055490, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007f7bf7b753c3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007f7bf7b75411 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x7f7bf358c000 (LWP 3403) "emacs"):
#0  pselect64_syscall (sigmask=<optimized out>, timeout=<optimized out>, exceptfds=0x0, writefds=0x7ffdfac20990, readfds=0x7ffdfac20910, nfds=19) at ../sysdeps/unix/sysv/linux/pselect.c:34
#1  __pselect (nfds=19, readfds=0x7ffdfac20910, writefds=0x7ffdfac20990, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:56
#2  0x000055c3d77cf035 in really_call_select (arg=0x7ffdfac20800) at thread.c:596
#3  0x000055c3d77cfe73 in flush_stack_call_func (arg=0x7ffdfac20800, func=0x55c3d77cefc0 <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=19, rfds=rfds@entry=0x7ffdfac20910, wfds=wfds@entry=0x7ffdfac20990, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdfac20f50, sigmask=0x0) at thread.c:628
#5  0x000055c3d77ed8d1 in xg_select (fds_lim=19, rfds=rfds@entry=0x7ffdfac21060, wfds=wfds@entry=0x7ffdfac210e0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdfac20f50, sigmask=sigmask@entry=0x0) at xgselect.c:147
#6  0x000055c3d77acb15 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  0x000055c3d76ede6c in kbd_buffer_get_event (end_time=0x0, used_mouse_menu=0x7ffdfac218eb, kbp=<synthetic pointer>) at keyboard.c:3926
#8  read_event_from_main_queue (used_mouse_menu=0x7ffdfac218eb, local_getcjmp=0x7ffdfac214f0, 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=0x55c3d96ec313, prev_event=0x0, used_mouse_menu=0x7ffdfac218eb, end_time=0x0) at keyboard.c:2892
#11 0x000055c3d76f04d4 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
#12 0x000055c3d76f1e9c in command_loop_1 () at keyboard.c:1392
#13 0x000055c3d7761a47 in internal_condition_case (bfun=bfun@entry=0x55c3d76f1ca0 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55c3d76e8490 <cmd_error>) at eval.c:1450
#14 0x000055c3d76e24be in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1133
#15 0x000055c3d7761989 in internal_catch (tag=tag@entry=0xe850, func=func@entry=0x55c3d76e2490 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1181
#16 0x000055c3d76e2459 in command_loop () at keyboard.c:1111
#17 0x000055c3d76e8080 in recursive_edit_1 () at keyboard.c:720
#18 0x000055c3d76e83d9 in Frecursive_edit () at keyboard.c:803
#19 0x000055c3d75f7054 in main (argc=1, argv=<optimized out>) at emacs.c:2354
Detaching from program: /usr/local/emacs-28.1/bin/emacs-28.1, process 3403
[Inferior 1 (process 3403) detached]

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

It was hanging. CPU was 0% on all the threads.

The suggestion of running emacsclient -t to save state was very
helpful. I used emacsclient -t, M-x desktop-save, M-x kill-emacs. Then
I started a new emacs and did M-x desktop-read to restore my previous
state.

bug#55726: 28.1; emacs becomes unresponsive to input

[Eli Zaretskii]

> Date: Sat, 18 Jun 2022 15:38:09 -0400
> From: "Jay Berkenbilt" <ejb@ql.org>
> 
> Thread 4 (Thread 0x7f7bf0917640 (LWP 3621) "dconf worker"):
> #0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d85854c0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x00007f7bf7b753c3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007f7bf0a3133d in  () at /usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
> #4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
> #6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 3 (Thread 0x7f7bf12bd640 (LWP 3503) "gdbus"):
> #0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d843aea0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x00007f7bf7b77293 in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007f7bf7dd2c1a in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
> #4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
> #6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 2 (Thread 0x7f7bf1b36640 (LWP 3410) "gmain"):
> #0  0x00007f7bf6427d7f in __GI___poll (fds=0x55c3d8055490, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007f7bf7bcc696 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #2  0x00007f7bf7b753c3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007f7bf7b75411 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x00007f7bf7ba6a41 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #5  0x00007f7bf63a3b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
> #6  0x00007f7bf6435a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> Thread 1 (Thread 0x7f7bf358c000 (LWP 3403) "emacs"):
> #0  pselect64_syscall (sigmask=<optimized out>, timeout=<optimized out>, exceptfds=0x0, writefds=0x7ffdfac20990, readfds=0x7ffdfac20910, nfds=19) at ../sysdeps/unix/sysv/linux/pselect.c:34
> #1  __pselect (nfds=19, readfds=0x7ffdfac20910, writefds=0x7ffdfac20990, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:56
> #2  0x000055c3d77cf035 in really_call_select (arg=0x7ffdfac20800) at thread.c:596
> #3  0x000055c3d77cfe73 in flush_stack_call_func (arg=0x7ffdfac20800, func=0x55c3d77cefc0 <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=19, rfds=rfds@entry=0x7ffdfac20910, wfds=wfds@entry=0x7ffdfac20990, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdfac20f50, sigmask=0x0) at thread.c:628
> #5  0x000055c3d77ed8d1 in xg_select (fds_lim=19, rfds=rfds@entry=0x7ffdfac21060, wfds=wfds@entry=0x7ffdfac210e0, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffdfac20f50, sigmask=sigmask@entry=0x0) at xgselect.c:147

Some GLib-related deadlock, perhaps?  The GLib context locking is a
can of worms; we do some jumping through hoops in xgselect.c to avoid
problems, but maybe that's not enough?

> > 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.
> 
> It was hanging. CPU was 0% on all the threads.

A.k.a. "deadlock".

Not sure how to continue from here.  xgselect.c had some changes
lately, so maybe you could try using Emacs 29 for a while and see if
these hangs don't happen there?

Thanks.

bug#55726: 28.1; emacs becomes unresponsive to input

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii [2022-06-19 08:38 +0300] wrote:

> Not sure how to continue from here.  xgselect.c had some changes
> lately, so maybe you could try using Emacs 29 for a while and see if
> these hangs don't happen there?

FWIW, I run master as my daily driver, and I'm pretty sure I've run into
this maybe once, at most twice since the latest relevant xgselect.c
changes.

-- 
Basil

bug#55726: 28.1; emacs becomes unresponsive to input

[Jay Berkenbilt]

On Sun, Jun 19, 2022, at 8:56 AM, Basil L. Contovounesios wrote:
> Eli Zaretskii [2022-06-19 08:38 +0300] wrote:
> 
> > Not sure how to continue from here.  xgselect.c had some changes
> > lately, so maybe you could try using Emacs 29 for a while and see if
> > these hangs don't happen there?
> 
> FWIW, I run master as my daily driver, and I'm pretty sure I've run into
> this maybe once, at most twice since the latest relevant xgselect.c
> changes.
> 
> -- 
> Basil
> 

Just to keep this alive, I still run into this on a regular basis. I
am pretty close to being able to come up with a formula to reproduce
it. I just have to take the time to do it. It always happens to me
when I exit an ediff session, and if I pause some time between using
"q" to exit the ediff session (which causes the little ediff frame to
disappear) and answering "y" to confirm that I want to exit the
session, this seems to greatly reduce the likelihood of a lockup.

I may spend some time on this. The last time there was a bug that was
causing emacs to crash on me regularly was around the release of
emacs 20. Thank goodness for the emacsclient -t workaround. At least
that way I am able to save my state fully before killing and restarting
emacs.