[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55726: 28.1; emacs becomes unresponsive to input
From: |
Eli Zaretskii |
Subject: |
bug#55726: 28.1; emacs becomes unresponsive to input |
Date: |
Sun, 19 Jun 2022 08:38:23 +0300 |
> 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.