[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: 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 <address@hidden>
> Cc: address@hidden, address@hidden
> > Date: Tue, 26 Aug 2014 11:34:11 -0700 (PDT)
> > From: Drew Adams <address@hidden>
> > Cc: address@hidden
> > 
> > > FWIW, I can't reproduce on GNU Emacs (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

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;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]