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

Previous Next

Full log

View this message in rfc822 format

From: "Jay Berkenbilt" <ejb <at> ql.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>, "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 55726 <at> debbugs.gnu.org
Subject: bug#55726: 28.1; emacs becomes unresponsive to input
Date: Sat, 28 Jan 2023 14:12:26 -0500

On Sun, Jun 19, 2022, at 8:56 AM, Basil L. Contovounesios wrote:
> Eli Zaretskii [2022-06-19 08:38 +0300] wrote:
> 
> > 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?
> 
> FWIW, I run master as my daily driver, and I'm pretty sure I've run into
> this maybe once, at most twice since the latest relevant xgselect.c
> changes.
> 
> -- 
> Basil
> 

Just to keep this alive, I still run into this on a regular basis. I
am pretty close to being able to come up with a formula to reproduce
it. I just have to take the time to do it. It always happens to me
when I exit an ediff session, and if I pause some time between using
"q" to exit the ediff session (which causes the little ediff frame to
disappear) and answering "y" to confirm that I want to exit the
session, this seems to greatly reduce the likelihood of a lockup.

I may spend some time on this. The last time there was a bug that was
causing emacs to crash on me regularly was around the release of
emacs 20. Thank goodness for the emacsclient -t workaround. At least
that way I am able to save my state fully before killing and restarting
emacs.

Previous Next

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