unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Barry OReilly <gundaetiapo@gmail.com>
Cc: 14281@debbugs.gnu.org
Subject: bug#14281: 24.3; replace-match leaves point at wrong place
Date: Tue, 14 May 2013 13:01:47 -0400	[thread overview]
Message-ID: <CAFM41H1f19mQPGDNH0doEaX8_C==aX798LsFW1Un2mY3qVrjgw@mail.gmail.com> (raw)
In-Reply-To: <jwvip2q36h3.fsf-monnier+emacs@gnu.org>


[-- Attachment #1.1: Type: text/plain, Size: 2114 bytes --]

> Can you show us the offenders?

Offenders and status:
   semantic-change-function      Fixed in CEDET mainline
   evil-ex-search-update-pattern Fixed in Evil mainline
   evil-track-last-insertion     See below
   Undo tree                     Haven't investigated

I'm not so sure search_regs are saved and restored through save-match-data.
I have this advice:

(defadvice evil-track-last-insertion (around
my-advice-evil-track-last-insertion activate)
  (my-msg "DEBUG: 01 evil-track-last-insertion match-data=%s
match-beginning=%s" (match-data) (match-beginning 0))
  (save-match-data ad-do-it)
  (my-msg "DEBUG: 02 evil-track-last-insertion match-data=%s
match-beginning=%s" (match-data) (match-beginning 0))
  )

Note: my-msg is like message but prefixes the time.

When I inserted a new line in a .cc file, I get:

2013-05-14T12:51:39.010590 DEBUG: 01 evil-track-last-insertion
match-data=(#<marker at 1 in FileNameRedacted.cc> #<marker at 5 in
FileNameRedacted.cc> #<marker at 4 in FileNameRedacted.cc> #<marker at 5 in
FileNameRedacted.cc>) match-beginning=0
2013-05-14T12:51:39.020153 DEBUG: 02 evil-track-last-insertion
match-data=(#<marker at 1 in FileNameRedacted.cc> #<marker at 5 in
FileNameRedacted.cc> #<marker at 4 in FileNameRedacted.cc> #<marker at 5 in
FileNameRedacted.cc>) match-beginning=1
ad-handle-definition: `semantic-change-function' got redefined
2013-05-14T12:51:39.023610 DEBUG: 01 semantic-change-function
match-beginning=1
2013-05-14T12:51:39.025341 DEBUG: 02 semantic-change-function
match-beginning=1
2013-05-14T12:51:39.025525 DEBUG: 01 c-after-change match-beginning=1
2013-05-14T12:51:39.026920 DEBUG: 02 c-after-change match-beginning=1
2013-05-14T12:51:39.027110 DEBUG: 01 jit-lock-after-change match-beginning=1
2013-05-14T12:51:39.027319 DEBUG: 02 jit-lock-after-change match-beginning=1
newline: Match data corrupted in after-change-functions. Consider using
save-match-data

In this case, the change of match-beginning from 0 to 1 in
evil-track-last-insertion causes the error.

For reference, I am currently using the attached patch, which incorporates
your feedback.

[-- Attachment #1.2: Type: text/html, Size: 2323 bytes --]

[-- Attachment #2: check-match-beginning.diff --]
[-- Type: application/octet-stream, Size: 5325 bytes --]

diff --git a/src/insdel.c b/src/insdel.c
index 8029291..db2147f 100644
--- a/src/insdel.c
+++ b/src/insdel.c
@@ -28,6 +28,7 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
 #include "buffer.h"
 #include "window.h"
 #include "blockinput.h"
+#include "regex.h"
 #include "region-cache.h"
 
 static void insert_from_string_1 (Lisp_Object, ptrdiff_t, ptrdiff_t, ptrdiff_t,
@@ -2034,6 +2035,14 @@ signal_after_change (ptrdiff_t charpos, ptrdiff_t lendel, ptrdiff_t lenins)
 
   specbind (Qinhibit_modification_hooks, Qt);
 
+  /* Change hook functions are expected to use save-match-data if using regexps.
+     This checks match-beginning to detect cases of hooks corrupting match-data.
+     TODO: Implement in signal_before_change too
+   */
+  Lisp_Object match_beginning = 0 < search_regs.num_regs ?
+                                make_number (search_regs.start[0]) :
+                                Qnil;
+
   if (!NILP (Vafter_change_functions))
     {
       Lisp_Object args[4];
@@ -2053,6 +2062,12 @@ signal_after_change (ptrdiff_t charpos, ptrdiff_t lendel, ptrdiff_t lenins)
       XSETCDR (rvoe_arg, Qt);
     }
 
+  if ( ! EQ (match_beginning, 0 < search_regs.num_regs ?
+                              make_number (search_regs.start[0]) :
+                              Qnil))
+    error ("Match data corrupted in after-change-functions. "
+           "Consider using save-match-data");
+
   if (buffer_has_overlays ())
     report_overlay_modification (make_number (charpos),
 				 make_number (charpos + lenins),
@@ -2061,12 +2076,24 @@ signal_after_change (ptrdiff_t charpos, ptrdiff_t lendel, ptrdiff_t lenins)
 				 make_number (charpos + lenins),
 				 make_number (lendel));
 
+  if ( ! EQ (match_beginning, 0 < search_regs.num_regs ?
+                              make_number (search_regs.start[0]) :
+                              Qnil))
+    error ("Match data corrupted in overlay modification hooks. "
+           "Consider using save-match-data");
+
   /* After an insertion, call the text properties
      insert-behind-hooks or insert-in-front-hooks.  */
   if (lendel == 0)
     report_interval_modification (make_number (charpos),
 				  make_number (charpos + lenins));
 
+  if ( ! EQ (match_beginning, 0 < search_regs.num_regs ?
+                              make_number (search_regs.start[0]) :
+                              Qnil))
+    error ("Match data corrupted in text property insertion hooks. "
+           "Consider using save-match-data");
+
   unbind_to (count, Qnil);
 }
 
diff --git a/src/regex.h b/src/regex.h
index 8fe7ba1..b4833dc 100644
--- a/src/regex.h
+++ b/src/regex.h
@@ -429,6 +429,24 @@ struct re_registers
   regoff_t *end;
 };
 
+/* Every call to re_match, etc., must pass &search_regs as the regs
+   argument unless you can show it is unnecessary (i.e., if re_match
+   is certainly going to be called again before region-around-match
+   can be called).
+
+   Since the registers are now dynamically allocated, we need to make
+   sure not to refer to the Nth register before checking that it has
+   been allocated by checking search_regs.num_regs.
+
+   The regex code keeps track of whether it has allocated the search
+   buffer using bits in the re_pattern_buffer.  This means that whenever
+   you compile a new pattern, it completely forgets whether it has
+   allocated any registers, and will allocate new registers the next
+   time you call a searching or matching function.  Therefore, we need
+   to call re_set_registers after compiling a new pattern or after
+   setting the match registers, so that the regex functions will be
+   able to free or re-allocate it properly.  */
+extern struct re_registers search_regs;
 
 /* If `regs_allocated' is REGS_UNALLOCATED in the pattern buffer,
    `re_match_2' returns information about at least this many registers
diff --git a/src/search.c b/src/search.c
index ea36133..ffbea28 100644
--- a/src/search.c
+++ b/src/search.c
@@ -59,25 +59,7 @@ static struct regexp_cache searchbufs[REGEXP_CACHE_SIZE];
 /* The head of the linked list; points to the most recently used buffer.  */
 static struct regexp_cache *searchbuf_head;
 
-
-/* Every call to re_match, etc., must pass &search_regs as the regs
-   argument unless you can show it is unnecessary (i.e., if re_match
-   is certainly going to be called again before region-around-match
-   can be called).
-
-   Since the registers are now dynamically allocated, we need to make
-   sure not to refer to the Nth register before checking that it has
-   been allocated by checking search_regs.num_regs.
-
-   The regex code keeps track of whether it has allocated the search
-   buffer using bits in the re_pattern_buffer.  This means that whenever
-   you compile a new pattern, it completely forgets whether it has
-   allocated any registers, and will allocate new registers the next
-   time you call a searching or matching function.  Therefore, we need
-   to call re_set_registers after compiling a new pattern or after
-   setting the match registers, so that the regex functions will be
-   able to free or re-allocate it properly.  */
-static struct re_registers search_regs;
+struct re_registers search_regs;
 
 /* The buffer in which the last search was performed, or
    Qt if the last search was done in a string;

  reply	other threads:[~2013-05-14 17:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-27  1:19 bug#14281: 24.3; replace-match leaves point at wrong place Barry OReilly
2013-05-09 19:07 ` Barry OReilly
2013-05-09 21:27   ` Stefan Monnier
2013-05-10 13:27     ` Barry OReilly
2013-05-10 18:19       ` Barry OReilly
2013-05-10 20:56         ` Stefan Monnier
2013-05-14 17:01           ` Barry OReilly [this message]
2013-05-15 15:03             ` Barry OReilly
2013-05-15 19:18               ` Stefan Monnier
2013-05-15 20:44                 ` Barry OReilly
2013-05-15 20:58                   ` Barry OReilly
2013-05-21 21:49                     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFM41H1f19mQPGDNH0doEaX8_C==aX798LsFW1Un2mY3qVrjgw@mail.gmail.com' \
    --to=gundaetiapo@gmail.com \
    --cc=14281@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).