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 15:28:36 -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> <83sj4ki5nw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1361824173 29858 80.91.229.3 (25 Feb 2013 20:29:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Feb 2013 20:29:33 +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 21:29:55 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 1UA4gI-0002rd-G3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 21:29:50 +0100 Original-Received: from localhost ([::1]:56940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4fx-0004lI-NR for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Feb 2013 15:29:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4fs-0004jZ-Ec for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:29:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UA4fp-0007uF-OE for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:29:24 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UA4fp-0007u5-KQ for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:29:21 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UA4hR-0002es-Vt for bug-gnu-emacs@gnu.org; Mon, 25 Feb 2013 15:31:02 -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 20:31: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.136182422110165 (code B ref 13743); Mon, 25 Feb 2013 20:31:01 +0000 Original-Received: (at 13743) by debbugs.gnu.org; 25 Feb 2013 20:30:21 +0000 Original-Received: from localhost ([127.0.0.1]:50027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA4gm-0002dt-Oc for submit@debbugs.gnu.org; Mon, 25 Feb 2013 15:30:21 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:16528) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UA4gk-0002dm-It for 13743@debbugs.gnu.org; Mon, 25 Feb 2013 15:30:19 -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="2429961" 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 15:28:35 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 828B56C0A9; Mon, 25 Feb 2013 15:28:36 -0500 (EST) In-Reply-To: <83sj4ki5nw.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Feb 2013 20:56:19 +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:71798 Archived-At: >> turn on overwrite-mode and replace the char at point with itself: >> sure enough the buffer is marked as modified. > Since you know how things work internally in this case, I'm surprised > that you bring this example. Actually, I don't really know how overwrite-mode works (I remembering seeing it some point, but that's about as much I know about it). > By contrast, in overwrite-mode we actually make the change without > trying to avoid it. That's an internal implementation detail, IMO. >> Along the same lines, try (setq t t) and watch how it complains that >> we're trying to modify a read-only object, ... > Feel free to fix this blunder. ;-) >> > 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. > If add-text-property was a black box, Why should we not consider it as a black box? > I might consider agreeing with you. But since it isn't, and its > algorithm is glaringly clear, I don't. I see nowhere (other than in its implementation) something that might lead one to think that it's clever. > The algorithm clearly tries to avoid mutation when possible, it just > didn't go far enough. Indeed, we could go further and reduce the interval passed to modify_region in the case where some of the leading/trailing part of the text already has the requested property values. All these are just optimizations (i.e. quality of implementation details, lack of which is not a bug). >> So, no I do not consider it to be a bug at all. > Not even considering the fact that it causes redisplay do redundant > work? If so, we will have to agree to disagree. No, not even considering it. >> >> 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. > So you think I should install the followup I showed earlier? I'd leaning towards yes, although it's sufficiently ugly (and dangerous since there's no reason to assume that it won't inf-loop) that I'd rather not. > Not with mmm-mode, it doesn't. If you repeat the original recipe for > the crash, putting a breakpoint in filelock.c where it calls > ask-user-about-lock, and type 'p' to the first prompt, you will get a > second prompt, triggered by jit-lock, which does use > with-silent-modifications, AFAICS. I didn't try to figure out why > this happens. Looks like a weird corner case, indeed. Maybe some code run from jit-lock ends up (re)setting byte-file-name (which is normally bound to nil by with-silent-modifications). Stefan