From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, 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: Tue, 19 Jul 2016 18:35:45 +0300 [thread overview]
Message-ID: <83a8hd1vzi.fsf__43208.2513849766$1468942809$gmane$org@gnu.org> (raw)
In-Reply-To: <jwv1t2q5jsz.fsf-monnier+emacsbugs@gnu.org> (message from Stefan Monnier on Tue, 19 Jul 2016 00:48:19 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rpluim@gmail.com, 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com
> Date: Tue, 19 Jul 2016 00:48:19 -0400
>
> > The more general problem is when there's at least one more
> > sub-expression, whose start and/or end are after the new EOB.
> > Those sub-expression's data will be completely bogus after the
> > adjustment,
>
> If they were after the EOB, they were already bogus to start with.
I think we are mis-communicating. I mean the following scenario:
Before call to replace_range in replace-match:
|---------------------------|---|------|----|
s1 e1 s2 e2 EOB
(s1, e1, etc. are the start and end of the corresponding
sub-expressions.)
After the call to replace_range in replace-match:
|---------|---|------|----|
s1 e1 s2 e2 EOB
IOW, the 1st sub-expression got replaced with a much shorter text,
which made EOB be smaller than the original beginning and end of the
2nd sub-expression. There's nothing bogus with this, is there? The
user will expect to get match-data adjusted as shown in the second
diagram, and that's what she will really get -- unless there are
buffer-modification hooks that use save-match-data. In the latter
case, what the user will get instead is this:
|---------|---|------|----|
s1 EOB
e1
s2
e2
and that is even before the adjustment code kicks in and makes
"adjustments" with an incorrect adjustment value, which is computed as
newpoint = search_regs.start[sub] + SCHARS (newtext);
[...]
ptrdiff_t change = newpoint - search_regs.end[sub];
and so will use the new EOB as search_regs.end[sub], instead of the
correct original value of e1 from the first diagram above.
IOW, the call to save-match-data in a buffer-modification hook
_disrupts_ the normal operation of replace-match in this case, by
indirectly sabotaging the adjustment of match data after the
replacement.
Am I missing something?
> And in any case, that's what has been happening for ever and has
> proved safe enough.
So you are saying that if a bug has been happening "for ever", it
doesn't have to be fixed? (I disagree about "safe enough": the amount
of bug reports in our data base that are not reproducible and about
whose reasons we have no clear idea is non-negligible, so we don't
really know whether this particular issue caused trouble in the past
or not.)
> >> So I think a safe fix is to try and relax the check we added to
> >> replace-match so it doesn't get all worked up when something ≥ EOB gets
> >> changed to something else that's also ≥ EOB.
> > And lose the other sub-expressions in a more general case? Really?
>
> I'm not sure what you mean by "losing sub-expressions".
See above: the match data for any sub-expressions beyond the one that
shrunk too much is now bogus. Thus "losing".
> >> Or maybe instead of signaling an error, we could simply skip the "Adjust
> >> search data for this change".
> > That would still sweep the problem under the carpet, leaving the match
> > data bogus, so I don't like doing that.
>
> Maybe I'm not 100% satisfied with the behavior either, but I don't think
> it's a significant problem and I don't think it'd cause the crash we saw
> in bug#23869.
We don't only solve bugs that cause crashes, do we? When I debugged
the crash in bug#23869, I found and tried to solve the root cause of
it, not just the symptom that caused the assertion violation. I still
think we should strive to solve the root cause.
As for the significance of the problem, I hope you will reconsider
this after reading the above description of the scenario I have in
mind. (Or tell me where I am wrong.)
> > The crash in bug#23869 was due to this:
> >
> > newpoint = search_regs.start[sub] + SCHARS (newtext);
> > [...]
> > /* Now move point "officially" to the start of the inserted replacement. */
> > move_if_not_intangible (newpoint); <<<<<<<<<<<<<<<<<<<<<<<
> >
> > because due to clobbering, newpoint became -1.
>
> Ah, I see.
>
> Then maybe another fix is to compute newpoint before we call
> replace_range, so it uses search_regs.start[sub] before the
> *-change-functions can mess it up. IOW:
>
> @@ -2726,9 +2726,9 @@ since only regular expressions have distinguished
> subexpressions. */)
> unsigned num_regs = search_regs.num_regs;
>
> /* Replace the old text with the new in the cleanest possible way. */
> + newpoint = search_regs.start[sub] + SCHARS (newtext);
> replace_range (search_regs.start[sub], search_regs.end[sub],
> newtext, 1, 0, 1);
> - newpoint = search_regs.start[sub] + SCHARS (newtext);
>
> if (case_action == all_caps)
> Fupcase_region (make_number (search_regs.start[sub]),
>
> Would that be sufficient to avoid the crash? Why not?
To avoid the crash in that particular use case, yes (but it can be
avoided even easier, by validating the value of newpoint before the
call to move_if_not_intangible). But what about the root cause? It
is a clear bug, and could even cause crashes, if one of the match-data
end-point positions becomes negative as result of the bogus
adjustment, and someone then uses those positions for something.
What's worse, these bugs happen in programs that are completely valid
on the Lisp level.
next prev parent reply other threads:[~2016-07-19 15:37 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
[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 [this message]
[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
[not found] ` <83fur2xjeu.fsf@gnu.org>
2016-07-22 14:01 ` Robert Pluim
2016-07-22 19:30 ` Nicolas Petton
2016-07-23 4:19 ` npostavs
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] ` <878twtqj6n.fsf_-_@moondust.awandering>
2016-07-23 7:38 ` 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='83a8hd1vzi.fsf__43208.2513849766$1468942809$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).