GNU bug report logs -
#75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Previous Next
Full log
Message #167 received at 75322 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
> Date: Sun, 05 Jan 2025 15:11:08 +0100
>
> Eli Zaretskii <eliz <at> 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.
This bug report was last modified 147 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.