[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55726: 28.1; emacs becomes unresponsive to input
From: |
Basil L. Contovounesios |
Subject: |
bug#55726: 28.1; emacs becomes unresponsive to input |
Date: |
Mon, 30 May 2022 17:36:35 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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