GNU bug report logs - #18331
24.4.50; REGRESSION, no `C-h k' for `C-g'

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: theonewiththeevillook <at> yahoo.fr, drew.adams <at> oracle.com,
 18331 <at> debbugs.gnu.org
Subject: Re: bug#18331: 24.4.50; REGRESSION, no `C-h k' for `C-g'
Date: Wed, 27 Aug 2014 18:30:15 +0300

> Date: Tue, 26 Aug 2014 21:51:44 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: theonewiththeevillook <at> yahoo.fr, 18331 <at> debbugs.gnu.org
> 
> > Date: Tue, 26 Aug 2014 11:34:11 -0700 (PDT)
> > From: Drew Adams <drew.adams <at> oracle.com>
> > Cc: 18331 <at> debbugs.gnu.org
> > 
> > > FWIW, I can't reproduce on GNU Emacs 24.4.50.3 (i686-pc-linux-gnu, GTK+
> > > Version 3.10.8) of 2014-08-26.
> > 
> > Hopefully someone else will try with MS Windows or other platforms.
> > 
> > For me (on Windows) it is 100% reproducible on all of the builds
> > I mentioned.
> 
> I do see it, but only after evaluating that strange form.  If I don't
> evaluate it, "C-h k" woks as expected.

This one was a bitch to debug.  It happens on the release branch as
well, so solving it is a somewhat urgent and delicate matter.

The root cause here is that we call specbind (inside message3_nolog)
with quit-flag non-nil.  What happens next is entirely unpredictable:
when specbind calls set_internal, the latter calls Fassq, which calls
QUIT after it examines every 4 members in the buffer's local
variables' list.  If you are unlucky, Emacs QUITs in the middle of
that, and the entire "C-h k" command gets silently aborted.

I have no idea why this works in Emacs 24.3 and how using the
custom-set-variables form causes it to fail in the current version.  I
did verify that in Emacs 24.3 we also call the same specbind with
quit-flag non-nil.  In the current sources, before I evaluate the
custom-set-variables form, the call to Fassq leaves the loop very
quickly, and thus avoids the QUIT.  This is all very strange, but I
think given the basic fact that Fassq is called when quit-flag is
non-nil, the rest is sheer luck (or lack thereof).

On GNU/Linux, I could only look into this in a -nw session, where we
never get to that specbind with quit-flag non-nil.  So the problem
doesn't happen.  Could someone please test this on GNU/Linux with a
GUI frame?  The place to put the breakpoint is on line 10574 of
xdisp.c (it's inside iwith_echo_area_buffer), and define the breakpoint
commands like this:

  p globals.f_Vquit_flag
  xsymbol
  continue
  end

Then run the recipe reported in the beginning of this bug discussion.

I can fix this problem with the simple patch below.  Does anyone see
any problems with it?

--- src/data.c~	2014-08-03 08:43:52 +0300
+++ src/data.c	2014-08-27 18:28:13 +0300
@@ -1311,10 +1311,10 @@ set_internal (Lisp_Object symbol, Lisp_O
 
 	    /* Find the new binding.  */
 	    XSETSYMBOL (symbol, sym); /* May have changed via aliasing.  */
-	    tem1 = Fassq (symbol,
-			  (blv->frame_local
-			   ? XFRAME (where)->param_alist
-			   : BVAR (XBUFFER (where), local_var_alist)));
+	    tem1 = assq_no_quit (symbol,
+				 (blv->frame_local
+				  ? XFRAME (where)->param_alist
+				  : BVAR (XBUFFER (where), local_var_alist)));
 	    set_blv_where (blv, where);
 	    blv->found = 1;
 

Previous Next

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