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#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Date: Mon, 25 Feb 2013 18:25:26 +0200 Message-ID: <831uc4jr7t.fsf@gnu.org> References: <5125ADA9.3070603@cs.ucla.edu> <51283965.2020107@yandex.ru> <837glzkqvc.fsf@gnu.org> <83621ilvk9.fsf@gnu.org> <512A31A0.4040804@yandex.ru> <83ehg5k8xe.fsf@gnu.org> <512AFC18.4090504@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1361809593 8599 80.91.229.3 (25 Feb 2013 16:26:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Feb 2013 16:26:33 +0000 (UTC) Cc: 13743@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 25 17:26:56 2013 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 1UA0tC-0007Z5-PI for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 17:26:54 +0100 Original-Received: from localhost ([::1]:43312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA0ss-0007MH-1T for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 11:26:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA0sl-0007Kk-HE for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 11:26:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UA0sh-0004hx-DT for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 11:26:27 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44352) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA0sh-0004hn-9c for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 11:26:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UA0uI-0004Ve-7a for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 11:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Feb 2013 16:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13743 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13743-submit@debbugs.gnu.org id=B13743.136180964317256 (code B ref 13743); Mon, 25 Feb 2013 16:28:02 +0000 Original-Received: (at 13743) by debbugs.gnu.org; 25 Feb 2013 16:27:23 +0000 Original-Received: from localhost ([127.0.0.1]:49816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA0te-0004UF-RB for submit@debbugs.gnu.org; Mon, 25 Feb 2013 11:27:23 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:58898) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA0ta-0004U3-Vj for 13743@debbugs.gnu.org; Mon, 25 Feb 2013 11:27:20 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0MIS000009EPYG00@a-mtaout21.012.net.il> for 13743@debbugs.gnu.org; Mon, 25 Feb 2013 18:25:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIS0006EAYKVL80@a-mtaout21.012.net.il>; Mon, 25 Feb 2013 18:25:33 +0200 (IST) In-reply-to: <512AFC18.4090504@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71787 Archived-At: > Date: Mon, 25 Feb 2013 09:52:24 +0400 > From: Dmitry Gutov > CC: monnier@iro.umontreal.ca, 13743@debbugs.gnu.org > > OTOH, the existing behavior in this area is rather messy anyway: > > a) If START equals to the beginning of the region with the same > property, the buffer is marked modified anyway (even though nothing > changes from the observer's point of view). > > So, the trivial example of repeating an `add-text-properties' call with > the same arguments in a previously unpropertized buffer will mark it as > modified every time. > > b) This probably has something to do with internal representation, but > even having the same property span before START is not a safe bet: That's a bug, actually, and a very old one at that (at least 17 years old, IIUC). The code didn't handle correctly all the situations where there's nothing to change, before it announced a change by calling modify_region (and later called signal_after_change). I installed on the trunk revision 111875 to fix this. Now all your examples: > 1. Create a new file with a line of text in it, preferably without > spaces, to see face changes easily > 2. Save it, disable font-lock-mode. > 3. Evaluate: > > (add-text-properties 1 6 '(face font-lock-constant-face)) => modified > save > (add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified > (add-text-properties 2 7 '(face font-lock-constant-face)) => modified > save > (add-text-properties 2 6 '(face font-lock-constant-face)) => unmodified > - optional step > (add-text-properties 2 7 '(face font-lock-constant-face)) => modified(!) > - even though 1 still has the same face > - you can save and repeat this step indefinitely work as expected. Interestingly, this also fixes the original segfault which started this discussion (not before I fixed similar bugs in remove-text-properties and elsewhere in textprop.c, because making the change only n add-text-properties still triggered a similar segfault from remove-text-properties). So perhaps the fact that buffer modifications were announced unnecessarily is the root cause for the segfault. I couldn't convince myself that, even after revision 111875, we could not end up in a situation where redisplay triggered by modify_region changes the intervals when it fontifies the buffer. So perhaps we need a followup patch to plumb that potential hole, something along the following: === modified file 'src/textprop.c' --- src/textprop.c 2013-02-25 16:13:42 +0000 +++ src/textprop.c 2013-02-25 16:23:43 +0000 @@ -1134,6 +1134,7 @@ Return t if any property value actually register int modified = 0; struct gcpro gcpro1; ptrdiff_t got; + int first_time = 1; properties = validate_plist (properties); if (NILP (properties)) @@ -1142,6 +1143,7 @@ Return t if any property value actually if (NILP (object)) XSETBUFFER (object, current_buffer); + retry: i = validate_interval_range (object, &start, &end, hard); if (!i) return Qnil; @@ -1174,8 +1176,25 @@ Return t if any property value actually copy_properties (unchanged, i); } - if (BUFFERP (object)) - modify_region (object, start, end); + if (BUFFERP (object) && first_time) + { + ptrdiff_t prev_total_length = TOTAL_LENGTH (i); + ptrdiff_t prev_pos = i->position; + + modify_region (object, start, end); + /* If someone called us recursively as a side effect of + modify_region, and changed the intervals behind our back + (could happen if lock_file, called by prepare_to_modify_buffer, + triggers redisplay, and that calls add-text-properties again + in the same buffer), we cannot continue with I, because its + data changed. So we restart the interval analysis anew. */ + if (TOTAL_LENGTH (i) != prev_total_length + || i->position != prev_pos) + { + first_time = 0; + goto retry; + } + } /* We are at the beginning of interval I, with LEN chars to scan. */ for (;;)