bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 04 Jan 2025 11:08:50 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, 75322@debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> > The current code in callproc.c assumes that GC cannot run while we are
> > parked in posix_spawn or vfork.
> 
> If you're attempting to explain why the current code is safe (if you're
> saying it is), it assumes much more than that.  call_process assumes
> Fexpand_file_name doesn't GC, for example, which seems unsafe to me: the
> function calls Lisp, which may do anything, including modifying
> Vprocess_environment.

AFAICT, expand-file-name is called before we start using the SSDATA of
strings in the args[] array.  Or what did I miss?

> Regardless of what you're saying, such assumptions need to be spelled
> out.  Where they are made, that is, not in a utility function.

I'm okay with spelling out these assumptions.

> Yes, make_environment_block does say its callers can't run GC, but
> call_process doesn't indicate when and how it establishes a no-GC
> assumption.

What would be needed to indicate that?

> > Is that assumption false with MPS?
> 
> As we agreed, code should be written to assume GC can strike at any
> time.

I don't think we agreed to that.  At least I didn't, not in this
general form.  It would be a huge job to make all of our code comply
with this.

> > Another question is about the global Lisp variables in 'globals'.  For
> > example, Vprocess_environment actually globals.f_Vprocess_environment.
> 
> > Is this large struct protected from GC, i.e. can GC ever decide that
> > process-environment is not used and free it?  If it's protected, where
> > and how is it protected?
> 
> It's a global variable.  Those are protected.
> 
> > And if it is protected, then any members of
> > the list that is the value of process-environment are also protected
> > and cannot be freed by GC.
> 
> IIUC, Gerd explained that the old GC can still move the string *data*
> used in that structure, even if the string metadata stays in place.

If string data is moved, then accessing the old pointer would trigger
the barrier and MPS will do its thing, not?

To clarify, I was trying to understand whether the error message
reported by Ihor in another thread could have happened because of GC
in this are of the code.