From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Jay Berkenbilt" <ejb@ql.org>
Cc: 55726@debbugs.gnu.org
Subject: bug#55726: 28.1; emacs becomes unresponsive to input
Date: Mon, 30 May 2022 17:36:35 +0300 [thread overview]
Message-ID: <87ee0bw0i4.fsf@tcd.ie> (raw)
In-Reply-To: <11874f4a-5f7c-4f88-923f-4a6310654697@www.fastmail.com> (Jay Berkenbilt's message of "Mon, 30 May 2022 08:58:26 -0400")
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
next prev parent reply other threads:[~2022-05-30 14:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 12:58 bug#55726: 28.1; emacs becomes unresponsive to input Jay Berkenbilt
2022-05-30 13:57 ` Eli Zaretskii
[not found] ` <aa78fc87-b4e8-4629-be45-466967885a55@www.fastmail.com>
2022-05-30 15:18 ` Jay Berkenbilt
2022-06-18 19:38 ` Jay Berkenbilt
2022-06-19 5:38 ` Eli Zaretskii
2022-06-19 12:56 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-28 19:12 ` Jay Berkenbilt
2022-05-30 14:36 ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-05-30 15:00 ` Jay Berkenbilt
2022-06-17 1:53 ` dick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee0bw0i4.fsf@tcd.ie \
--to=bug-gnu-emacs@gnu.org \
--cc=55726@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=ejb@ql.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).