Subject: bug#55726: 28.1; emacs becomes unresponsive to input

From: "Basil L. Contovounesios" <[email-masked]>
Date: Mon, 30 May 2022 17:36:35 +0300

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