GNU bug report logs - #29347
27.0.50; C-g doesn't quit minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mike Gerwitz <mtg <at> gnu.org>
Cc: 29370 <at> debbugs.gnu.org, 29347 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: bug#29347: 27.0.50; C-g doesn't quit minibuffer
Date: Fri, 24 Nov 2017 18:17:58 +0200

> From: Mike Gerwitz <mtg <at> gnu.org>
> Cc: rms <at> gnu.org,  29347 <at> debbugs.gnu.org
> Date: Mon, 20 Nov 2017 15:26:36 -0500
> 
> On Mon, Nov 20, 2017 at 20:36:38 +0200, Eli Zaretskii wrote:
> >> I can reproduce it simply with `emacs -Q -nsl -nw' (it must be a TTY;
> >> GUI emacs does not suffer from this bug): quickly press `C-f C-f C-g'.
> >
> > Do you mean "C-x C-f C-g"?
> 
> I'm sorry, I meant `C-x C-f C-x C-f C-g` (attempt a recursive
> minibuffer).  I was in a rush typing the original message.

I think I fixed the problem which caused Emacs to hang in this
particular scenario, but I'm not sure Richard is seeing the same
problem.  The change I installed on the emacs-26 branch is below;
Richard, please try applying it, and see if your problems go away.

diff --git a/src/thread.c b/src/thread.c
index c03cdda..1ded8f5 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -97,7 +97,12 @@ post_acquire_global_lock (struct thread_state *self)
 static void
 acquire_global_lock (struct thread_state *self)
 {
-  sys_mutex_lock (&global_lock);
+  /* If some Lisp was interrupted by C-g while inside pselect, the
+     signal handler could have called maybe_reacquire_global_lock, in
+     which case we are already holding the lock and shouldn't try
+     taking it again, or else we will hang forever.  */
+  if (!(self && self->not_holding_lock))
+    sys_mutex_lock (&global_lock);
   post_acquire_global_lock (self);
 }
 

Previous Next

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