bug#43499: 27.1; It is possible for (forward-comment -1) to crash emacs

[Alan Mackenzie]

Hello, Jeff.

Thanks for taking the trouble to report this bug, and thanks also for
analysing it and proposing a patch to fix it.

On Fri, Sep 18, 2020 at 20:25:33 -0500, Jeff Norden wrote:
> In an unusual circumstance, (forward-comment -1) can move the point before the
> accessible buffer text.  This can even result in the point becoming negative.
> In the worst-case scenario, emacs becomes completely unresponsive, and it
> might even be necessary to reboot the computer.

> Instructions for those who want to verify this bug are below.  But the
> explanation and fix are fairly simple, so I'll start with that.

> The problem is the following code for forward-comment, from syntax.c starting
> at line 2542 (emacs-27.1).  This is in the 2nd part of the function, which is
> the code that runs when forward-comment is called with a negative arg to move
> backwards.  I've marked two relevant lines with * and **.

[ Analysis and fix snipped for now. ]

> ------------------------------
> Here are instructions for verifying this bug.  The behavior below is what I've
> observed under linux with the mate and gnome3 desktops.  I don't know what
> will happen under ms-windows or macos.

> 1) Please be sure that there are no open applications with unsaved data.
> Obviously, don't try this on a mission-critical server.

> 2) The safest thing is to run 'emacs -nw -Q' from a terminal window.  Or, use
> a linux console, as long as you will be able to switch to another console to
> kill emacs.

> 3) Open a plain fundamental-mode buffer.  Do "M-x modify-syntax-entry @ !" to
> make the at-sign into a generic fence comment character.  Then put

> @This is a fenced comment@

> at the start of the buffer. The first at-sign should be the first character of
> the buffer.

> 4) Try 'M-: (forward-comment -1)' with the cursor at the start of the second 
> line.
> The cursor should move to the beginning of the buffer, verifying that the
> first line is a comment.

> 5) Now place the cursor on the 'T' after the first at-sign, so the point is
> between them, at the 2nd buffer position.  Do 'M-: (forward-comment -1)'
> again, and emacs should be dead.
> ------------------------------

I can confirm that there is a bug, here.  When I do the above on Emacs
28 master in a Linux TTY, I get a segfault.

I agree with the OP that this needs fixing, and his fix [snipped] is
likely a good one.

[ .... ]

> AFAICT, there doesn't seem to be a similar problem with (forward-comment +1).

No.  At this level, forward and backwards movement over comments use
different code.

> ==============================
> In case you are wondering how I stumbled onto this, in CWEB (the Knuth/Levy
> literate programming system) sections are defined and referenced with the
> following syntax:

> @<Description of a section of code@>

> One way to highlight these is to set the syntax-table property of the initial
> '@' and the final '>' to comment-fence, which also prevents the description
> itself from being interpreted as code.  A CWEB file won't ever start with this
> construct, but the definition of a code section does, and it is useful to
> temporarily narrow the buffer to a section of code, including its name.

> When I traced the source of args-out-of-range errors to forward-comment, I
> realized that narrowing the buffer wasn't even necessary.  When I tested that
> hypothesis, emacs froze up my desktop.

Interesting!

> -Jeff

> ============================================================
> In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo 
> version 1.17.3)
>  of 2020-08-28 built on juergen
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: Manjaro Linux

-- 
Alan Mackenzie (Nuremberg, Germany).