From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55726: 28.1; emacs becomes unresponsive to input Date: Mon, 30 May 2022 16:57:50 +0300 Message-ID: <83fskrjf6p.fsf@gnu.org> References: <11874f4a-5f7c-4f88-923f-4a6310654697@www.fastmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13941"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55726@debbugs.gnu.org To: "Jay Berkenbilt" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 30 16:03:45 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nvfzX-0002vX-H5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 May 2022 16:03:31 +0200 Original-Received: from localhost ([::1]:59416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nvfzO-0004CH-8J for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 May 2022 10:03:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38928) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvfvD-0001HY-2o for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 09:59:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51680) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nvfvC-0002mD-0c for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 09:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nvfvC-0000kn-0H for bug-gnu-emacs@gnu.org; Mon, 30 May 2022 09:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 May 2022 13:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55726 X-GNU-PR-Package: emacs Original-Received: via spool by 55726-submit@debbugs.gnu.org id=B55726.16539190862762 (code B ref 55726); Mon, 30 May 2022 13:59:01 +0000 Original-Received: (at 55726) by debbugs.gnu.org; 30 May 2022 13:58:06 +0000 Original-Received: from localhost ([127.0.0.1]:45577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvfuH-0000iU-Ag for submit@debbugs.gnu.org; Mon, 30 May 2022 09:58:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45252) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvfu6-0000hZ-Mo for 55726@debbugs.gnu.org; Mon, 30 May 2022 09:58:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38328) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvfu1-0002dx-6N; Mon, 30 May 2022 09:57:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ihyb+k/sAGaQ4paSJs6vm6OCUYINOJ7FVVhA2R/6pxA=; b=muRRf8kc07DV 6EJH8j3QMsaiuPjmjKmneYe0lqj629TjH0Fbsuv4IUKLd9Kxhyw+LQyCoUsp/bvZEDMrB1ijcP9V7 k0F7f3KOrzVKWZHZIt9dR2caNjRUcW6ORMUTpDKtc56w+ZPxMLJOHRHCwB2Z+NgwdaNptVQv0YvNu YN0B03CnIh/A2AzyOayaJ6JuPLhUeEglrLw4r32QXh4SBxiEcgihiVSyK8h01I+3CvDXhrDlpb23A jDXUl248Gt9umHZM3UAfyOPAddQDtisf5NlyInPHUOnttdOsDvvCL5058rmNdfx2E+VfkGM86jmva +8hJgtMCDVZFTCER43WwrA==; Original-Received: from [87.69.77.57] (port=2520 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvftz-00006q-W3; Mon, 30 May 2022 09:57:48 -0400 In-Reply-To: <11874f4a-5f7c-4f88-923f-4a6310654697@www.fastmail.com> (ejb@ql.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233376 Archived-At: > Cc: ejb@ql.org > Date: Mon, 30 May 2022 08:58:26 -0400 > From: "Jay Berkenbilt" > > 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=, timeout=, 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=, sigmask=) 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 ) at /home/ejb/tmp/net/emacs-28.1/src/lisp.h:3834 > #4 thread_select (func=, 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=) 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=, prev_event=, local_getcjmp=, end_time=) 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=, prompt=0x0, dont_downcase_last=, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=) 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.