From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template =?UTF-8?Q?=E2=80=98g=E2=80=99:?= Match data clobbered by buffer modification hooks) Date: Tue, 19 Jul 2016 05:40:11 +0300 Message-ID: <83eg6q1hbo.fsf@gnu.org> References: <87vb066ejv.fsf@linaro.org> <8360s67qcp.fsf@gnu.org> <87bn1yyaui.fsf@linaro.org> <87mvlhmv0x.fsf_-_@moondust.awandering> <837fcl5zs9.fsf@gnu.org> <87a8hgkwcb.fsf@linaro.org> <8360s42mcb.fsf@gnu.org> <87eg6rgmlg.fsf@gmail.com> <83lh0y24y6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1468896235 14474 80.91.229.3 (19 Jul 2016 02:43:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jul 2016 02:43:55 +0000 (UTC) Cc: 23917@debbugs.gnu.org, rpluim@gmail.com, jwiegley@gmail.com, alex.bennee@linaro.org, nljlistbox2@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 19 04:43:42 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bPL0X-0007Rh-FH for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jul 2016 04:43:41 +0200 Original-Received: from localhost ([::1]:51542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPL0W-0004Xr-8X for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Jul 2016 22:43:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPKy5-0001mJ-58 for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2016 22:41:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPKy4-00084D-3D for bug-gnu-emacs@gnu.org; Mon, 18 Jul 2016 22:41:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPKxy-00081r-DZ; Mon, 18 Jul 2016 22:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bPKxy-0003eT-6U; Mon, 18 Jul 2016 22:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Tue, 19 Jul 2016 02:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23917 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: Original-Received: via spool by 23917-submit@debbugs.gnu.org id=B23917.146889603113988 (code B ref 23917); Tue, 19 Jul 2016 02:41:02 +0000 Original-Received: (at 23917) by debbugs.gnu.org; 19 Jul 2016 02:40:31 +0000 Original-Received: from localhost ([127.0.0.1]:56143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPKxS-0003dY-NE for submit@debbugs.gnu.org; Mon, 18 Jul 2016 22:40:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bPKxQ-0003dH-68 for 23917@debbugs.gnu.org; Mon, 18 Jul 2016 22:40:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPKxJ-0007tT-OO for 23917@debbugs.gnu.org; Mon, 18 Jul 2016 22:40:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPKxB-0007qw-42; Mon, 18 Jul 2016 22:40:13 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3160 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bPKx9-0004AS-2h; Mon, 18 Jul 2016 22:40:11 -0400 In-reply-to: (message from Stefan Monnier on Mon, 18 Jul 2016 20:58:35 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:121251 Archived-At: > From: Stefan Monnier > Cc: Robert Pluim , 23917@debbugs.gnu.org, alex.bennee@linaro.org, jwiegley@gmail.com, nljlistbox2@gmail.com > Date: Mon, 18 Jul 2016 20:58:35 -0400 > > > 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. > > I think this change performed by save-match-data is harmless: the old > value (62) was not valid any more anyway. In this particular case, yes. But only in this case, because (a) there's actually only one sub-expression, and (b) it ends exactly at EOB. 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, should the buffer-modification hooks use save-match-data. > 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? > 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. > This said, I don't fully understand what's going on: bug#23869 reported > a crash, but AFAICT the match-data here is only used to adjust > search_regs which seems like it wouldn't cause a crash, even if the new > values are bogus. 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. > > - '((save-match-data-internal (match-data))) > > + '((save-match-data-internal (match-data 'integers))) > > That looks risky. Then how about manually doing the equivalent of save-match-data around the call to replace_range, calling match-data with non-nil argument?