[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).