From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org
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 [thread overview]
Message-ID: <jwvwqtwqha5.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83sj4ki5nw.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Feb 2013 20:56:19 +0200")
>> 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
next prev parent reply other threads:[~2013-02-25 20:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
2013-02-19 0:52 ` Dmitry Gutov
2013-02-20 19:31 ` Eli Zaretskii
2013-02-21 8:30 ` Dmitry Gutov
2013-02-18 19:35 ` Glenn Morris
2013-02-19 0:55 ` Dmitry Gutov
2013-02-21 5:16 ` Paul Eggert
2013-02-21 7:03 ` Dmitry Gutov
2013-02-23 3:37 ` Dmitry Gutov
2013-02-23 15:10 ` Eli Zaretskii
2013-02-23 16:59 ` Stefan Monnier
2013-02-23 18:44 ` Eli Zaretskii
2013-02-24 15:28 ` Dmitry Gutov
2013-02-24 15:50 ` Eli Zaretskii
2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
2013-02-25 16:37 ` Eli Zaretskii
2013-02-25 18:29 ` Stefan Monnier
2013-02-25 18:56 ` Eli Zaretskii
2013-02-25 20:28 ` Stefan Monnier [this message]
2013-02-26 3:39 ` Eli Zaretskii
2013-02-26 4:35 ` Stefan Monnier
2013-03-02 9:30 ` Eli Zaretskii
2013-02-25 16:25 ` Eli Zaretskii
2013-02-25 18:27 ` Dmitry Gutov
2013-02-25 16:27 ` Eli Zaretskii
2013-02-25 19:08 ` Dmitry Gutov
2013-02-25 19:31 ` Eli Zaretskii
2013-02-25 23:23 ` Dmitry Gutov
2013-02-26 3:51 ` Eli Zaretskii
2013-02-26 3:59 ` Dmitry Gutov
2013-02-26 18:42 ` Eli Zaretskii
2013-02-27 17:46 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvwqtwqha5.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=13743@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.