From: Eli Zaretskii <eliz@gnu.org>
To: "Jay Berkenbilt" <ejb@ql.org>
Cc: 55726@debbugs.gnu.org
Subject: bug#55726: 28.1; emacs becomes unresponsive to input
Date: Sun, 19 Jun 2022 08:38:23 +0300 [thread overview]
Message-ID: <831qvlnrg0.fsf@gnu.org> (raw)
In-Reply-To: <a0f0ec53-21c7-46d9-9dc5-cf150ab1c0a3@www.fastmail.com> (ejb@ql.org)
> 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.
next prev parent reply other threads:[~2022-06-19 5:38 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831qvlnrg0.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=55726@debbugs.gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.