bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#18022: 24.3; Emacs hard locks when attempting to do a replacement wi


From: Alan Mackenzie
Subject: bug#18022: 24.3; Emacs hard locks when attempting to do a replacement with ^M in it.
Date: Sat, 19 Jul 2014 20:33:10 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hello, Stefan, Marty and Eli.

On Wed, Jul 16, 2014 at 09:41:44PM +0000, Alan Mackenzie wrote:
> On Tue, Jul 15, 2014 at 07:46:08PM +0300, Eli Zaretskii wrote:
> > Alan, can you take a look?

> OK, I've made some progress.  Just to be specific what the problem is:
> When in 64-bit Gnu/Linux, a C++ file is exactly this (where ^M is a
> carriage return)

> template <bool b>^MSimulatorBase<b>::foobar()

> (there being no newline at EOB), font-locking hangs, though hitting a
> frame changing command followed by C-g often enough will switch frames.

OK.  The problem is in forward-comment.  If you put point on the S after
the ^M and do M-: (forward-comment -1), point moves one character
forward.  This leads to an infinite loop in CC Mode code.  (Note: for
this to manifest, the buffer must, at some stage, have had font lock
enabled, setting up some text properties).

The immediate cause of this is in Fforward_comment at ~L+168:

          else if (code == Sendcomment)
            {
------->      found = back_comment (from, from_byte, stop, comnested, comstyle,
                                    &out_charpos, &out_bytepos);
              if (!found)

Before the call to back_comment, "print SYNTAX(13)" in gdb returns
(correctly) Sendcomment.  After back_comment returns, it returns Sclose.
(In fact SYNTAX(x), for any x, returns Sclose).  So back_comment plays
with the current syntax table structure, and fails to restore it
properly - it appears that rather than restoring it for ^M, it is setting
up the (syntax table property) value of >.  13 lines lower down, we have:

                      if (SYNTAX (c) != code)
                        /* It was a two-char Sendcomment.  */
------------>           INC_BOTH (from, from_byte);
                      goto leave;

This spurious call to INC_BOTH is what causes the buggy character
movement forwards.

Looking at back_comment, just after the main loop at L+205, we have the
code which restores point and the current syntax table:

  if (comstart_pos == 0)
    {
      from = comment_end;
      from_byte = comment_end_byte;
=>    UPDATE_SYNTAX_TABLE_FORWARD (comment_end - 1);
    }

It seems to me that that " - 1" is what is causing the syntax table to be
restored to the value for ">", and shouldn't be there.  Stefan, am I
right?

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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