GNU bug report logs - #24074
25.1.50; c-before-after-change-digit-quote: Invalid search bound (wrong side of point)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24074 in the body.
You can then email your comments to 24074 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: bug-gnu-emacs <at> gnu.org, "Alan Mackenzie" <acm <at> muc.de>
Subject: 25.1.50;
 c-before-after-change-digit-quote: Invalid search bound (wrong side
 of point)
Date: Tue, 26 Jul 2016 17:50:28 +0200

From time to time, after performing a git operation that changes files'
contents (switch branch, apply a stash, etc) and automatically reverting
the associated buffers, the error mentioned on the subject line happens.
In that case the affected buffer's contents is truncated and is marked
as modified.

This only happens with C++ buffers and I suspect that it depends on the
cursor position at the time of the revert. Sadly, I have no recipe for
replicating it.

The problem was first observed a few weeks ago, which coincides with the
introduction of the mentioned function. An Emacs version built on 6th of
June works fine.

In GNU Emacs 25.1.50.3 (x86_64-pc-linux-gnu, X toolkit)
 of 2016-07-24 built on qcore
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 16.04.1 LTS

Configured using:
 'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE XFT ZLIB LUCID X11

Important settings:
  value of $LANG: C
  locale-coding-system: nil

Major mode: Emacs-Lisp

Minor modes in effect:
  TeX-PDF-mode: t
  show-paren-mode: t
  diff-auto-refine-mode: t
  global-git-commit-mode: t
  shell-dirtrack-mode: t
  column-overflow-mode: t
  ido-grid-mode: t
  flx-ido-mode: t
  ido-hacks-mode: t
  ido-everywhere: t
  buffer-flip-mode: t
  evil-leader-mode: t
  evil-paredit-mode: t
  paredit-mode: t
  evil-mode: t
  evil-local-mode: t
  global-anzu-mode: t
  anzu-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

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

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 24094 <at> debbugs.gnu.org, 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: 29 Jul 2016 17:59:24 -0000

Hello, Richard.

In article <mailman.2189.1469713866.26859.bug-gnu-emacs <at> gnu.org> you wrote:
> When editing C++ files, if I change visited files outside emacs (for
> example, by doing "svn revert -R ."), then visit one of the changed
> files and accept the offer to revert the buffer, in some cases there
> is an error (see below) and the buffer contents are corrupted (chunks
> are missing because the revert operation was interrupted).

This looks like the same bug as bug #24074, but you've managed to capture
a backtrace, for which many thanks.

Could you be a bit more descriptive about the "chunks" that are missing,
please?  Are we talking about lots of isolated 2-character chunks, or
just one or two larger chunks, or what?  Are the chunks at the end of a
buffer, or in the "middle" of it?

> I haven't been able to reduce this to a recipe and I don't know if
> the issue is present in the emacs-25 branch and/or in "emacs -Q".

Almost certainly, the bug isn't in the emacs-25 branch, because the
function c-before-after-change-digit-quote isn't in that branch.

> Here is an example backtrace (control characters replaced):

> Debugger entered--Lisp error: (error "Invalid search bound (wrong side
> of point)")
>   re-search-forward("[0-9a-fA-F]'[0-9a-fA-F]" 175 t)
>   c-before-after-change-digit-quote(65 65 1625)
>   #[(fn) "^H    \n^K#\207" [fn beg end old-len]
> 4](c-before-after-change-digit-quote)
>   mapc(#[(fn) "^H    \n^K#\207" [fn beg end old-len] 4]
> (c-depropertize-new-text c-extend-font-lock-region-for-macros
> c-before-after-change-digit-quote c-after-change-re-mark-raw-strings
> c-neutralize-syntax-in-and-mark-CPP c-restore-<>-properties
> c-change-expand-fl-region))
>   c-after-change(65 65 1625)
>   insert-file-contents("g:/projects/polymorph/working3/src/settings.cpp"
> t nil nil t)
>   revert-buffer-insert-file-contents--default-function("g:/projects/polymorph/working3/src/settings.cpp"
> nil)
>   revert-buffer--default(t t)
>   revert-buffer(t t)
>   find-file-noselect("g:/projects/polymorph/working3/src/settings.cpp")
>   compilation-find-file(#<marker at 1397 in *grep*> "settings.cpp" nil)
>   apply(compilation-find-file #<marker at 1397 in *grep*>
> "settings.cpp" nil nil)
>   compilation-next-error-function(1 nil)
>   next-error(nil)
>   funcall-interactively(next-error nil)
>   call-interactively(next-error nil nil)
>   command-execute(next-error)


> In GNU Emacs 25.1.50.1 (x86_64-w64-mingw32)
>  of 2016-07-25 built on MACHINE
> Repository revision: 6dc6b0079ed3632ed9082bc79d8cb6fc96d33f43
> Windowing system distributor 'Microsoft Corp.', version 10.0.10586
> Recent messages:
> Undo!
> Saving file g:/projects/polymorph/working3/src/model.cpp...
> Wrote g:/projects/polymorph/working3/src/model.cpp
> Reverted 'model.cpp'
> Undo!
> Saving file g:/projects/polymorph/working3/src/model.cpp...
> Wrote g:/projects/polymorph/working3/src/model.cpp
> Reverted 'model.cpp'
> Undo!
> Entering debugger...

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Richard Copley <rcopley <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 24094 <at> debbugs.gnu.org, 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 19:16:50 +0100

On 29 July 2016 at 18:59, Alan Mackenzie <acm <at> muc.de> wrote:
> Hello, Richard.

Hi!

> In article <mailman.2189.1469713866.26859.bug-gnu-emacs <at> gnu.org> you wrote:
>> When editing C++ files, if I change visited files outside emacs (for
>> example, by doing "svn revert -R ."), then visit one of the changed
>> files and accept the offer to revert the buffer, in some cases there
>> is an error (see below) and the buffer contents are corrupted (chunks
>> are missing because the revert operation was interrupted).
>
> This looks like the same bug as bug #24074, but you've managed to capture
> a backtrace, for which many thanks.

Yes, I think it is likely the same bug (if I'd noticed #24074 sooner,
I would have sent the backtrace there). Happy to help.

> Could you be a bit more descriptive about the "chunks" that are missing,
> please?  Are we talking about lots of isolated 2-character chunks, or
> just one or two larger chunks, or what?  Are the chunks at the end of a
> buffer, or in the "middle" of it?

It's hard to describe precisely (especially as I don't have a
corrupted buffer here and now), but being guided by your question,
we're talking about one or two larger chunks and not at the end of the
buffer but in the "middle".

My impression FWIW is that it is *as if* Emacs has done
"diff-buffer-with-file" and is attempting to apply the resulting patch
to the buffer (perhaps with the laudable intention of saving space in
the undo buffer), and has failed after a deletion and before an
insertion. But that is uninformed speculation.

>> I haven't been able to reduce this to a recipe and I don't know if
>> the issue is present in the emacs-25 branch and/or in "emacs -Q".
>
> Almost certainly, the bug isn't in the emacs-25 branch, because the
> function c-before-after-change-digit-quote isn't in that branch.

That's useful to know.
Thanks Alan.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Richard Copley <rcopley <at> gmail.com>, 24094 <at> debbugs.gnu.org,
 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 20:29:49 +0200

Alan Mackenzie <acm <at> muc.de> writes:

> Could you be a bit more descriptive about the "chunks" that are missing,
> please?  Are we talking about lots of isolated 2-character chunks, or
> just one or two larger chunks, or what?  Are the chunks at the end of a
> buffer, or in the "middle" of it?

It just happened again here. The missing chunk is everything below the
first 9 lines (the file has ~400 lines). Those preserved lines are
simply #include's. The final preserved line was truncated to

#include <

The original was

#include <string.h>

Prior the revert, the point was much below that 9nth line.

The reported failure is not always the same. In this case was:

c-determine-+ve-limit: Args out of range: #<buffer rawmem.cpp>, -7246, -6746


Or course, now that I'm trying to cause the error for obtaining an stack
trace, it doesn't happen :-( As mentioned on my bug report, it seems
that the problem is triggered when the point falls on certain places
on the reverted file's contents, but that's just my guess.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Óscar Fuentes <ofv <at> wanadoo.es>
Cc: Alan Mackenzie <acm <at> muc.de>, 24094 <at> debbugs.gnu.org, 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 19:41:39 +0100

On 29 July 2016 at 19:29, Óscar Fuentes <ofv <at> wanadoo.es> wrote:
> Alan Mackenzie <acm <at> muc.de> writes:
>
>> Could you be a bit more descriptive about the "chunks" that are missing,
>> please?  Are we talking about lots of isolated 2-character chunks, or
>> just one or two larger chunks, or what?  Are the chunks at the end of a
>> buffer, or in the "middle" of it?
>
> It just happened again here. The missing chunk is everything below the
> first 9 lines (the file has ~400 lines). Those preserved lines are
> simply #include's. The final preserved line was truncated to
>
> #include <
>
> The original was
>
> #include <string.h>
>
> Prior the revert, the point was much below that 9nth line.
>
> The reported failure is not always the same. In this case was:
>
> c-determine-+ve-limit: Args out of range: #<buffer rawmem.cpp>, -7246, -6746
>
>
> Or course, now that I'm trying to cause the error for obtaining an stack
> trace, it doesn't happen :-( As mentioned on my bug report, it seems
> that the problem is triggered when the point falls on certain places
> on the reverted file's contents, but that's just my guess.

Here is a recipe.

Prepare a file "test0.cpp" as follows: (<<END)
int main () {
  int a = 0;
  int b = 1;
  int c = 2;
  int d = 3;
}
END

In a shell: cp test0.cpp test.cpp
In Emacs: visit test.cpp, transpose "line b" and "line c", save the
buffer, and put point between the transposed lines (i.e., at the
beginning of "line b").
In the shell: cp test0.cpp test.cpp
In Emacs: revisit test.cpp (C-x f M-n RET).

I hope that helps.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 24094 <at> debbugs.gnu.org, 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 20:43:03 +0200

Richard Copley <rcopley <at> gmail.com> writes:

> It's hard to describe precisely (especially as I don't have a
> corrupted buffer here and now), but being guided by your question,
> we're talking about one or two larger chunks and not at the end of the
> buffer but in the "middle".

Yes, sometimes the missing chunk(s) are in the middle of the file. AFAIR
they are always quite large. I can't confirm the case of more than one
chunk, though.

Appreciating the damage is complicated by the fact that it not evident
what's missing at first sight: in the case I describe on my previous
email, when the error happened and swtiched to the affected buffer it
only displayed one line (the first one); then, pressed cursor-down and
the other eight lines appeared from nowhere.

> My impression FWIW is that it is *as if* Emacs has done
> "diff-buffer-with-file" and is attempting to apply the resulting patch
> to the buffer (perhaps with the laudable intention of saving space in
> the undo buffer), and has failed after a deletion and before an
> insertion. But that is uninformed speculation.

I suspected some undo-related problem when I experienced the problem
some weeks ago. Then, disabled undo before the revert on my Magit code:

-            (revert-buffer t t)
+            (progn
+              (setq buffer-undo-list t)
+              (revert-buffer t t)

to no avail. It looks more like a cache issue to me now: c-mode is using
some stale info computed before the revert.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Alan Mackenzie <acm <at> muc.de>, 24094 <at> debbugs.gnu.org, 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 21:01:34 +0200

Richard Copley <rcopley <at> gmail.com> writes:

> Here is a recipe.
>
> Prepare a file "test0.cpp" as follows: (<<END)
> int main () {
>   int a = 0;
>   int b = 1;
>   int c = 2;
>   int d = 3;
> }
> END
>
> In a shell: cp test0.cpp test.cpp
> In Emacs: visit test.cpp, transpose "line b" and "line c", save the
> buffer, and put point between the transposed lines (i.e., at the
> beginning of "line b").
> In the shell: cp test0.cpp test.cpp
> In Emacs: revisit test.cpp (C-x f M-n RET).

Great! I can reproduce here with `emacs -Q'. It is important to note
that the `transpose' step above means `M-x transpose-lines' (or its
corresponding shorcut). Transposing with C-k <down> C-y invalidates the
recipe.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Richard Copley <rcopley <at> gmail.com>
Cc: Óscar Fuentes <ofv <at> wanadoo.es>, 24094 <at> debbugs.gnu.org,
 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 21:18:24 +0000

Hello, Richard and Óscar.

I've cracked it!

On Fri, Jul 29, 2016 at 07:41:39PM +0100, Richard Copley wrote:

> Here is a recipe.

> Prepare a file "test0.cpp" as follows: (<<END)
> int main () {
>   int a = 0;
>   int b = 1;
>   int c = 2;
>   int d = 3;
> }
> END

> In a shell: cp test0.cpp test.cpp
> In Emacs: visit test.cpp, transpose "line b" and "line c", save the
> buffer, and put point between the transposed lines (i.e., at the
> beginning of "line b").
> In the shell: cp test0.cpp test.cpp
> In Emacs: revisit test.cpp (C-x C-f M-n RET).

> I hope that helps.

Very much indeed.  What is happening in that sequence is that the C-x C-f
calls the hook after-change-functions without having first called
before-change-functions.  This screws up CC Mode.

The function doing this, insert-file-contents, is called as follows:
(insert-file-contents "test.cpp" t nil nil t)
                                 | |   |   |
                                 | |   |   replace
                                 | |   end
                                 | beg
                                 visit

The section of Finsert_file_contents which calls before-change-functions
(through prepare_to_modify_buffer) looks like this:

  if (NILP (visit) && total > 0)
    {
      if (!NILP (BVAR (current_buffer, file_truename))
          /* Make binding buffer-file-name to nil effective.  */
          && !NILP (BVAR (current_buffer, filename))
          && SAVE_MODIFF >= MODIFF)
        we_locked_file = true;
      prepare_to_modify_buffer (PT, PT, NULL);  <======================
    }

The brace block will not be executed since `visit' is t.

The section of code which calls after-change-functions looks like this:

  if (inserted > 0 && total > 0
      && (NILP (visit) || !NILP (replace)))
    {
      signal_after_change (PT, 0, inserted);     <=====================
      update_compositions (PT, PT, CHECK_BORDER);
    }

The brace block here _will_ get called, since `replace' is non-nil.
There are thus two different, conflicting, conditions governing whether
to call the change hooks.  At a guess, the `if' condition around the
after-change-functions call was modified at some stage, without the same
change being made to the condition around the before-change-functions
call.

I'll look into this further over the weekend.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Richard Copley <rcopley <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Óscar Fuentes <ofv <at> wanadoo.es>, 24094 <at> debbugs.gnu.org,
 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 22:34:59 +0100

On 29 July 2016 at 22:18, Alan Mackenzie <acm <at> muc.de> wrote:
> Hello, Richard and Óscar.
>
> I've cracked it!

In record time! Great stuff, and thanks for the explanation.

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

From: Óscar Fuentes <ofv <at> wanadoo.es>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Richard Copley <rcopley <at> gmail.com>, 24094 <at> debbugs.gnu.org,
 24074 <at> debbugs.gnu.org
Subject: Re: bug#24094: 25.1.50; revert-buffer error in CC mode
Date: Fri, 29 Jul 2016 23:59:53 +0200

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Richard and Óscar.
>
> I've cracked it!

[snip]

As expected :-)

> I'll look into this further over the weekend.

Thank you Alan.

Previous Next

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