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

Previous Next

Full log

Message #17 received at 55726 <at> debbugs.gnu.org (full text, mbox):

From: "Jay Berkenbilt" <ejb <at> ql.org>
To: 55726 <at> debbugs.gnu.org
Subject: Re: bug#55726: 28.1; emacs becomes unresponsive to input
Date: Mon, 30 May 2022 11:18:01 -0400

oops -- accidentally left bug address off my previous reply...

On Mon, May 30, 2022, at 9:57 AM, Eli Zaretskii wrote:
> > Cc: ejb <at> ql.org
> > Date: Mon, 30 May 2022 08:58:26 -0400
> > From: "Jay Berkenbilt" <ejb <at> ql.org>
> > 
>> . . .
> > 
> > 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:
> > 
> > . . .
> 
> 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.

I will do it next time it happens. Thanks.

> 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.

I don't think the CPU was spinning, but I can't guarantee. I will also
check this the next time it happens.

> > 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.

I don't think it is. My elisp/startup.el defines a function called
"qstartup". If I run emacs -Q, (fboundp 'qstartup) is nil, and if I
run with my environment, (fboundp qstartup) is t. Anyway, I don't
think there's anything in the build process that would read my .emacs,
and my .emacs has been loading ~/elisp/startup.el for decades. I'm not
aware of this ever having caused a problem, but I could consider
renaming the file. I'll wait to make that change until I have a
reliable way to reproduce the problem. Thanks -- this is definitely
something to account for.

Previous Next

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