From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: Conservative GC isn't safe
Date: Sat, 26 Nov 2016 11:24:38 +0200 [thread overview]
Message-ID: <831sxy386h.fsf@gnu.org> (raw)
In-Reply-To: <dca090ba-1eea-8c4f-1b1c-6edd97915666@dancol.org> (message from Daniel Colascione on Sat, 26 Nov 2016 01:04:18 -0800)
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Daniel Colascione <dancol@dancol.org>
> Date: Sat, 26 Nov 2016 01:04:18 -0800
>
> On 11/26/2016 01:01 AM, Eli Zaretskii wrote:
> >> From: Daniel Colascione <dancol@dancol.org>
> >> Date: Sat, 26 Nov 2016 00:33:13 -0800
> >>
> >>>> 2) INTERVAL is GCed, but it's not represented in the memory tree:
> >>>> struct interval isn't a real lisp object and it's allocated as
> >>>> MEM_TYPE_NON_LISP. Even a direct pointer to the start of an interval
> >>>> won't protect it from GC. Shouldn't we treat intervals like conses?
> >>>
> >>> Does the code ever create an interval that is accessible only via locals
> >>> when a GC occurs? If not, Emacs should be OK. (This should also be
> >>> documented better.)
> >>
> >> Anywhere in the code? Forever? I wouldn't be confident saying so.
> >
> > A simple practical solution to such assumptions is to add an assertion
> > in some strategic place(s).
> >
> > I don't think it's TRT to sprinkle our sources with code that is there
> > "just in case", i.e. it will never actually run.
>
> How would you assert dynamically that if an interval is reachable, its
> owning string or buffer must be too? It's not enough for the variable
> holding the reference to the string or buffer to be in scope: you have
> to be sure that the reference isn't dead.
I don't understand the use case you have in mind. Why would an
interval be created that is not reachable from the interval tree of
some Lisp object?
next prev parent reply other threads:[~2016-11-26 9:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-26 8:11 Conservative GC isn't safe Daniel Colascione
2016-11-26 8:30 ` Paul Eggert
2016-11-26 8:33 ` Daniel Colascione
2016-11-26 9:01 ` Eli Zaretskii
2016-11-26 9:04 ` Daniel Colascione
2016-11-26 9:24 ` Eli Zaretskii [this message]
2016-11-26 15:05 ` Stefan Monnier
2016-11-26 15:21 ` Camm Maguire
2016-11-28 17:51 ` Daniel Colascione
2016-11-28 18:00 ` Eli Zaretskii
2016-11-28 18:03 ` Daniel Colascione
2016-11-28 18:50 ` Eli Zaretskii
2016-11-28 18:03 ` Stefan Monnier
2016-11-28 19:18 ` Daniel Colascione
2016-11-28 19:33 ` Stefan Monnier
2016-11-28 19:37 ` Eli Zaretskii
2016-11-28 19:40 ` Daniel Colascione
2016-11-28 20:03 ` Eli Zaretskii
2016-11-28 20:09 ` Daniel Colascione
2016-11-28 19:26 ` Andreas Schwab
2016-11-28 19:34 ` Stefan Monnier
2016-11-26 15:03 ` Stefan Monnier
2016-11-26 15:12 ` Eli Zaretskii
2016-11-26 16:29 ` Stefan Monnier
2016-11-26 16:42 ` Eli Zaretskii
2016-11-26 18:43 ` Stefan Monnier
2016-11-27 6:17 ` Ken Raeburn
2016-11-27 15:39 ` Eli Zaretskii
2016-11-28 9:50 ` Ken Raeburn
2016-11-28 15:55 ` Eli Zaretskii
2016-11-27 16:15 ` Paul Eggert
2016-11-28 9:36 ` Ken Raeburn
2016-11-28 15:55 ` Eli Zaretskii
2016-11-28 16:15 ` Stefan Monnier
2016-11-28 17:37 ` Eli Zaretskii
2016-11-28 17:49 ` Stefan Monnier
2016-11-28 17:57 ` Eli Zaretskii
2016-11-28 18:05 ` Stefan Monnier
2016-11-28 19:09 ` Ken Raeburn
2016-11-28 19:33 ` Eli Zaretskii
2016-11-29 8:49 ` Ken Raeburn
2016-11-28 17:03 ` Björn Lindqvist
2016-11-28 16:13 ` Paul Eggert
2016-11-27 16:52 ` Stefan Monnier
2016-11-26 19:08 ` Pip Cet
2016-11-27 0:24 ` Paul Eggert
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831sxy386h.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dancol@dancol.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).