From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org
Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sun, 05 Jan 2025 19:45:43 +0200 [thread overview]
Message-ID: <86msg56to8.fsf@gnu.org> (raw)
In-Reply-To: <m2v7uttkoz.fsf@gmail.com> (message from Gerd Möllmann on Sun, 05 Jan 2025 15:11:08 +0100)
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org
> Date: Sun, 05 Jan 2025 15:11:08 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > And if GC _can_ happen,
> > but we don't use the allocated block again, is that a problem? For
> > example, in this fragment:
> >
> > SAFE_NALLOCA (args2, 1, nargs + 1);
> > args2[0] = Qcall_process;
> > for (i = 0; i < nargs; i++) args2[i + 1] = args[i];
> > coding_systems = Ffind_operation_coding_system (nargs + 1, args2);
> > val = CONSP (coding_systems) ? XCDR (coding_systems) : Qnil;
> >
> > Let's say Ffind_operation_coding_system could trigger GC. But we
> > never again use the args2[] array after Ffind_operation_coding_system
> > returns. Is the above still unsafe? If so, could you tell what
> > could MPS do during GC to make this unsafe?
>
> Let me first say why I find this unsafe in the old GC, in principle. If
> we don't assume anything about the objects referenced from args2, then a
> reference in args2 may well be the only one to some object. In this
> case, the old GC would sweep it.
OK, but in most, if not all of these cases, the objects are referenced
from the stack. For example, in the above fragment, the args[] array
is on the stack. Right?
> Not using arg2 after Ffind_operation_coding_system above is not enough.
> It would have to be not using args2 after the GC has run. Maybe that's
> _in_ Ffind_operation_coding_system.
OK, agreed.
> Additionally, objects might not die but may move, assuming that
> SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA
> makes another assumption in the MPS case: that something else prevents
> the objects from moving. Another proof or check required with my GCPRO
> hat on.
What does it mean in detail "the object may move"? A Lisp object is a
tagged pointer. Do you mean the pointer should no point to a
different address, i.e. the value of a Lisp object as a number should
change to still be valid? And if so, is MPS supposed to find all the
copies of that value everywhere in order to update them? So if I have
several variables which were all assigned a value of the same Lisp
object, they all need to be updated when the object moves?
> > Also, in some other message you said SAFE_NALLOCA is unsafe if
> > _pointers_ to Lisp objects are placed in the memory SAFE_NALLOCA
> > allocates off the heap. In call_process I see that we only ever put
> > Lisp objects into the memory allocated by SAFE_NALLOCA. If that is
> > unsafe, could you tell what MPS does during GC which makes this
> > unsafe?
>
> Not sure, is the question why in MPS both pointers and Lisp_Object count
> as "references"?
Yes, if that's the situation. Earlier you only mentioned pointers to
Lisp objects, something that happens relatively rarely.
next prev parent reply other threads:[~2025-01-05 17:45 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-03 17:20 bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-03 19:55 ` Gerd Möllmann
2025-01-03 20:34 ` Gerd Möllmann
2025-01-03 20:48 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 4:40 ` Gerd Möllmann
2025-01-04 7:57 ` Eli Zaretskii
2025-01-04 8:47 ` Gerd Möllmann
2025-01-04 9:56 ` Eli Zaretskii
2025-01-04 10:20 ` Gerd Möllmann
2025-01-05 13:30 ` Eli Zaretskii
2025-01-05 14:11 ` Gerd Möllmann
2025-01-05 17:45 ` Eli Zaretskii [this message]
2025-01-05 18:17 ` Gerd Möllmann
2025-01-05 19:07 ` Eli Zaretskii
2025-01-05 20:04 ` Gerd Möllmann
2025-01-05 20:24 ` Eli Zaretskii
2025-01-06 3:57 ` Gerd Möllmann
2025-01-06 8:25 ` Gerd Möllmann
2025-01-06 14:07 ` Eli Zaretskii
2025-01-05 21:15 ` Daniel Colascione
2025-01-06 12:59 ` Eli Zaretskii
2025-01-06 14:48 ` Daniel Colascione
2025-01-06 15:12 ` Eli Zaretskii
2025-01-06 15:27 ` Daniel Colascione
2025-01-05 21:01 ` Daniel Colascione
2025-01-05 23:28 ` Daniel Colascione
2025-01-06 13:26 ` Eli Zaretskii
2025-01-06 15:08 ` Daniel Colascione
2025-01-06 4:23 ` Gerd Möllmann
2025-01-04 11:41 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 11:29 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 12:17 ` Gerd Möllmann
2025-01-04 7:00 ` Eli Zaretskii
2025-01-04 7:17 ` Gerd Möllmann
2025-01-04 8:23 ` Eli Zaretskii
2025-01-04 8:58 ` Gerd Möllmann
2025-01-04 11:08 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 13:47 ` Eli Zaretskii
2025-01-04 14:13 ` Gerd Möllmann
2025-01-04 15:26 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 15:34 ` Gerd Möllmann
2025-01-04 18:19 ` Eli Zaretskii
2025-01-04 18:35 ` Gerd Möllmann
2025-01-04 19:10 ` Eli Zaretskii
2025-01-04 19:24 ` Gerd Möllmann
2025-01-04 18:02 ` Eli Zaretskii
2025-01-04 19:32 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-04 20:31 ` Eli Zaretskii
2025-01-04 21:15 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 8:23 ` Eli Zaretskii
2025-01-05 9:04 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 9:32 ` Eli Zaretskii
2025-01-05 9:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 11:04 ` Eli Zaretskii
2025-01-06 15:54 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-06 19:16 ` Gerd Möllmann
2025-01-08 3:46 ` Gerd Möllmann
2025-01-05 6:32 ` Gerd Möllmann
2025-01-05 6:59 ` Gerd Möllmann
2025-01-05 10:21 ` Eli Zaretskii
2025-01-05 10:30 ` Gerd Möllmann
2025-01-05 10:35 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 10:45 ` Gerd Möllmann
2025-01-05 11:29 ` Eli Zaretskii
2025-01-05 11:37 ` Gerd Möllmann
2025-01-05 12:15 ` Eli Zaretskii
2025-01-05 13:21 ` Gerd Möllmann
2025-01-05 17:31 ` Eli Zaretskii
2025-01-05 17:49 ` Gerd Möllmann
2025-01-05 18:42 ` Eli Zaretskii
2025-01-05 19:02 ` Gerd Möllmann
2025-01-05 7:48 ` Eli Zaretskii
2025-01-05 8:19 ` Gerd Möllmann
2025-01-05 10:33 ` Eli Zaretskii
2025-01-05 10:40 ` Gerd Möllmann
2025-01-05 11:21 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-05 11:27 ` Gerd Möllmann
2025-01-05 11:49 ` Paul Eggert
2025-01-06 6:26 ` Gerd Möllmann
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=86msg56to8.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=75322@debbugs.gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.com \
/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.