GNU bug report logs - #55726
28.1; emacs becomes unresponsive to input

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Jay Berkenbilt" <ejb <at> ql.org>
Cc: 55726 <at> debbugs.gnu.org
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 <at> 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 <at> entry=19, rfds=rfds <at> entry=0x7ffdfac20910, wfds=wfds <at> entry=0x7ffdfac20990, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffdfac20f50, sigmask=0x0) at thread.c:628
> #5  0x000055c3d77ed8d1 in xg_select (fds_lim=19, rfds=rfds <at> entry=0x7ffdfac21060, wfds=wfds <at> entry=0x7ffdfac210e0, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffdfac20f50, sigmask=sigmask <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.