From: Eli Zaretskii <eliz@gnu.org>
To: Robert Pluim <rpluim@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 23917@debbugs.gnu.org, jwiegley@gmail.com,
alex.bennee@linaro.org, nljlistbox2@gmail.com
Subject: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Date: Mon, 18 Jul 2016 21:09:53 +0300 [thread overview]
Message-ID: <83lh0y24y6.fsf__47424.3592507721$1468865525$gmane$org@gnu.org> (raw)
In-Reply-To: <87eg6rgmlg.fsf@gmail.com> (message from Robert Pluim on Mon, 18 Jul 2016 14:24:59 +0200)
> From: Robert Pluim <rpluim@gmail.com>
> CC: 23917@debbugs.gnu.org, Alex Bennée
> <alex.bennee@linaro.org>, jwiegley@gmail.com, nljlistbox2@gmail.com
> Date: Mon, 18 Jul 2016 14:24:59 +0200
>
> (I'm moving this discussion to the bug, let me know if that's not OK)
Thanks.
> Make sure that you have org-20160704 from elpa.
>
> # emacs -Q
>
> ;evaluate the following
> (custom-set-variables
> '(package-selected-packages
> (quote
> (org-20160704))))
> (package-initialize)
>
> ; Now do:
>
> C-x C-f ~/.notes
> M-x org-mode
> M-x org-capture
> t
>
> ; This should result in:
> Capture template ‘t’: Match data clobbered by buffer modification
> hooks
Thanks again.
It turns out the validation added in 3a9d6296, to solve bug#23869,
exposed a very serious bug we seem to have always had with
save-match-data called from buffer-modification hooks.
The basic problem is that set-marker restricts the buffer position
passed as its argument to valid limits, between 1 and EOB. So if you
call set-marker with a value beyond EOB, the marker's position will
silently set to EOB.
Now, when buffer-modification hooks run due to changes made by
replace-match, the replacement has already been done. If that
replacement shrinks the buffer, then when save-match-data is called,
and calls match-data, the latter will see the new (smaller) value of
EOB. By default, match-data records the data in markers it creates
for beginning and end of each matched sub-expression. So the result
is that beginning and/or end of any sub-expression that was beyond the
new EOB will be recorded as EOB. Then restoring this saved match data
will clobber the data of those sub-expressions.
In the case in point, a single character at EOB (= 62) was deleted,
which made EOB be 61, one less than its previous value. When
save-match-data was called from within a hook set up by Org, it tried
to record the end of the sub-expression as 62, but set-marker silently
changed that to 61. That "corrected" value was subsequently restored
when save-match-data was exited, whereas replace-match expected to see
the original value of 62, and therefore barfed.
My suggestion to fix this is below. I ask for opinions on (1) whether
this looks like TRT, (2) whether it is safe enough for emacs-25, and
(3) whether someone has better ideas. If someone thinks I've
misunderstood the issue, don't hesitate to explain why, because
frankly it feels very strange to find bugs that seem to have existed
since 1990.
diff --git a/lisp/subr.el b/lisp/subr.el
index e9e19d3..1bb1cb3 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3466,7 +3466,7 @@ save-match-data
;; if you need to recompile all the Lisp files using interpreted code.
(declare (indent 0) (debug t))
(list 'let
- '((save-match-data-internal (match-data)))
+ '((save-match-data-internal (match-data 'integers)))
(list 'unwind-protect
(cons 'progn body)
;; It is safe to free (evaporate) markers immediately here,
next prev parent reply other threads:[~2016-07-18 18:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87vb066ejv.fsf@linaro.org>
[not found] ` <8360s67qcp.fsf@gnu.org>
[not found] ` <87bn1yyaui.fsf@linaro.org>
[not found] ` <CAM-tV-9Befm+jtvvO9tZsYwCbzgggumNgWeuPzV-i=ZB0mgPog@mail.gmail.com>
[not found] ` <87mvlhmv0x.fsf_-_@moondust.awandering>
[not found] ` <837fcl5zs9.fsf@gnu.org>
[not found] ` <m28tx1o6h6.fsf@newartisans.com>
[not found] ` <87a8hgkwcb.fsf@linaro.org>
[not found] ` <8360s42mcb.fsf@gnu.org>
2016-07-18 12:24 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) Robert Pluim
2016-07-18 14:50 ` Kaushal Modi
[not found] ` <9613abde4dbd48fdb2b5e780101a13a0@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
2016-07-18 16:59 ` Eric S Fraga
[not found] ` <87eg6rgmlg.fsf@gmail.com>
2016-07-18 18:09 ` Eli Zaretskii [this message]
[not found] ` <83lh0y24y6.fsf@gnu.org>
2016-07-18 19:04 ` John Wiegley
2016-07-18 19:10 ` Eli Zaretskii
2016-07-19 0:58 ` Stefan Monnier
[not found] ` <jwvmvle5udz.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 2:40 ` Eli Zaretskii
[not found] ` <83eg6q1hbo.fsf@gnu.org>
2016-07-19 4:48 ` Stefan Monnier
[not found] ` <jwv1t2q5jsz.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 15:35 ` Eli Zaretskii
[not found] ` <83a8hd1vzi.fsf@gnu.org>
2016-07-19 16:03 ` Stefan Monnier
[not found] ` <jwvzipdeibv.fsf-monnier+emacsbugs@gnu.org>
2016-07-19 16:13 ` Eli Zaretskii
[not found] ` <834m7l1u8u.fsf@gnu.org>
2016-07-19 17:05 ` bug#23917: " Alex Bennée
[not found] ` <87a8hdmuce.fsf@linaro.org>
2016-07-19 17:20 ` Eli Zaretskii
[not found] ` <8337n51r4f.fsf@gnu.org>
2016-07-19 17:45 ` Alex Bennée
[not found] ` <878twxmshj.fsf@linaro.org>
2016-07-19 18:07 ` Sebastian Wiesner
2016-07-19 18:44 ` Eli Zaretskii
2016-07-20 9:48 ` bug#23917: " Alex Bennée
[not found] ` <877fcgmygy.fsf@linaro.org>
2016-07-20 14:59 ` Eli Zaretskii
2016-07-20 1:50 ` Stefan Monnier
[not found] ` <jwvd1m9dran.fsf-monnier+emacsbugs@gnu.org>
2016-07-20 14:55 ` Eli Zaretskii
[not found] ` <83shv4z7e8.fsf@gnu.org>
2016-07-20 18:19 ` Stefan Monnier
2016-07-20 18:55 ` Eli Zaretskii
[not found] ` <83inw0yw9q.fsf@gnu.org>
2016-07-20 20:54 ` Stefan Monnier
[not found] ` <jwvtwfkvxsc.fsf-monnier+emacsbugs@gnu.org>
2016-07-21 0:56 ` npostavs
[not found] ` <87bn1rdd1f.fsf@users.sourceforge.net>
2016-07-21 1:47 ` Stefan Monnier
[not found] ` <jwvzipb3gx0.fsf-monnier+emacsbugs@gnu.org>
2016-07-21 2:34 ` Noam Postavsky
[not found] ` <CAM-tV-9rqqOF=zjsXx3QQ5_z0n-fFB7-BCbxWdzb9EA_u2ZHPQ@mail.gmail.com>
2016-07-21 3:06 ` Stefan Monnier
2016-07-21 2:43 ` Eli Zaretskii
[not found] ` <83h9bjzp5i.fsf@gnu.org>
2016-07-21 3:00 ` npostavs
[not found] ` <877fcfd79w.fsf@users.sourceforge.net>
2016-07-21 14:26 ` Eli Zaretskii
[not found] ` <83a8hbysmw.fsf@gnu.org>
2016-07-22 1:08 ` npostavs
[not found] ` <874m7icwdg.fsf@users.sourceforge.net>
2016-07-22 6:43 ` Eli Zaretskii
2016-07-23 0:42 ` bug#23917: Re: bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
[not found] ` <83fur2xjeu.fsf@gnu.org>
2016-07-22 14:01 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) Robert Pluim
2016-07-22 19:30 ` Nicolas Petton
2016-07-23 4:19 ` npostavs
[not found] ` <878twtqj6n.fsf_-_@moondust.awandering>
2016-07-23 7:38 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out Eli Zaretskii
2016-07-21 7:59 ` N. Jackson
[not found] ` <87a8hb2zgt.fsf_-___1286.15575745261$1469088239$gmane$org@moondust.awandering>
2016-07-21 8:19 ` Robert Pluim
[not found] ` <8760sgnvxh.fsf@gmail.com>
[not found] ` <83lh1ci5x5.fsf@gnu.org>
[not found] ` <87poqo6sud.fsf@gmail.com>
2016-07-08 17:03 ` Eli Zaretskii
[not found] ` <83a8hshxjs.fsf@gnu.org>
2016-07-15 19:46 ` Eli Zaretskii
2016-07-21 14:24 ` N. Jackson
2016-07-19 23:18 ` bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks) npostavs
2016-07-19 15:36 ` Eli Zaretskii
2016-07-21 7:52 ` bug#23917: 25.0.95; commit 3a9d6296b35e5317c497674d5725eb52699bd3b8 causing org-capture to error out N. Jackson
[not found] ` <87h9bj2zsl.fsf_-_@moondust.awandering>
2016-07-21 8:08 ` Robert Pluim
[not found] ` <87poq7xvjy.fsf@gmail.com>
2016-07-21 13:19 ` N. Jackson
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.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='83lh0y24y6.fsf__47424.3592507721$1468865525$gmane$org@gnu.org' \
--to=eliz@gnu.org \
--cc=23917@debbugs.gnu.org \
--cc=alex.bennee@linaro.org \
--cc=jwiegley@gmail.com \
--cc=monnier@iro.umontreal.ca \
--cc=nljlistbox2@gmail.com \
--cc=rpluim@gmail.com \
/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/org-mode.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).