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: 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 23:41:11 +0200

> Date: Fri, 24 Nov 2017 23:14:16 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 29370 <at> debbugs.gnu.org, 29347 <at> debbugs.gnu.org, rms <at> gnu.org
> 
> > Date: Fri, 24 Nov 2017 18:17:58 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > Cc: 29370 <at> debbugs.gnu.org, 29347 <at> debbugs.gnu.org, rms <at> gnu.org
> > 
> > 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.
> 
> Sorry, wrong patch.  Please use the one below instead.

Sorry again, that was not the best idea.  Here is a better patch:

diff --git a/src/thread.c b/src/thread.c
index 9e799ce..dd46681 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -578,8 +573,15 @@ really_call_select (void *arg)
 			   sa->timeout, sa->sigmask);
 
   block_interrupt_signal (&oldset);
-  acquire_global_lock (self);
-  self->not_holding_lock = 0;
+  /* If we were interrupted by C-g while inside sa->func above, 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->not_holding_lock)
+    {
+      acquire_global_lock (self);
+      self->not_holding_lock = 0;
+    }
   restore_signal_mask (&oldset);
 }
 

Previous Next

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