From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 13:29:57 -0500 Message-ID: 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> <83y5ecic2p.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361817031 21919 80.91.229.3 (25 Feb 2013 18:30:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Feb 2013 18:30:31 +0000 (UTC) Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 25 19:30:51 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 1UA2p6-0000EF-BD for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 19:30:48 +0100 Original-Received: from localhost ([::1]:42081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA2ol-0000To-IN for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 13:30:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA2oi-0000Sv-H5 for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 13:30:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UA2og-0002nC-Kl for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 13:30:24 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA2og-0002n4-GS for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 13:30:22 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UA2qH-0007M8-Ib for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 13:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Feb 2013 18:32:01 +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.136181710828258 (code B ref 13743); Mon, 25 Feb 2013 18:32:01 +0000 Original-Received: (at 13743) by debbugs.gnu.org; 25 Feb 2013 18:31:48 +0000 Original-Received: from localhost ([127.0.0.1]:49880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA2q3-0007Li-Kw for submit@debbugs.gnu.org; Mon, 25 Feb 2013 13:31:48 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:7438) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA2pz-0007LY-MZ for 13743@debbugs.gnu.org; Mon, 25 Feb 2013 13:31:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+KLv/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFHO+KLv/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="2419934" Original-Received: from 206-248-162-239.dsl.teksavvy.com (HELO pastel.home) ([206.248.162.239]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 25 Feb 2013 13:30:01 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7BA886C0A9; Mon, 25 Feb 2013 13:29:57 -0500 (EST) In-Reply-To: <83y5ecic2p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Feb 2013 18:37:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:71790 Archived-At: >> >> The manifestation of the problem will be that modify_region will be >> >> called in this case, although we don't actually modify anything. You >> >> will probably see the "modified" indicator on the mode line, something >> >> that shouldn't have happened. >> > That is indeed what happens. >> > OTOH, the existing behavior in this area is rather messy anyway: >> Not only that, but it's not clear why "that shouldn't have happened". > Because we announce that the buffer was changed when in fact it > wasn't. That's a lie. (It also causes redisplay to work harder as a > side effect.) That's a widespread "lie". E.g. turn on overwrite-mode and replace the char at point with itself: sure enough the buffer is marked as modified. Along the same lines, try (setq t t) and watch how it complains that we're trying to modify a read-only object, ... > You can repeat the last 2 steps forever, the buffer always becomes > modified. I don't see how this could be anything but a bug. Not a > catastrophe, I agree, but a bug nonetheless. add-text-property is a mutation operation, like setq. Whether or not it returns data about the "old state" doesn't make it less of a side-effecting operation, in my eyes. So, no I do not consider it to be a bug at all. Try (add-text-properties 2 10 '(foo nil)) for another corner case: the `foo' property was already nil (by default), and yet add-text-properties claims that setting it to nil is a modification. >> And I don't think it's an important one here, since (as Dmitry points >> out) the likely most common case (of having `start' be right at the >> beginning of an interval object) didn't work anyway > It does work now. More importantly, it fixed the original crash. I suspect it only works around the crash by optimizing away the call to modify_region in the particular case you're testing. >> and furthermore most calls to add-text-properties are likely to be >> protected by inhibit-modification-hooks. > I don't think inhibit-modification-hooks stops the file-locking prompt > from being shown, does it? Well, I meant not just inhibit-modification-hooks but with-silent-modifications (or a comparable set of let-bindings and unwind-protect), which does prevent the prompt. Stefan