GNU bug report logs - #75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd.moellmann <at> gmail.com, 75322 <at> debbugs.gnu.org
Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sat, 04 Jan 2025 15:47:10 +0200

> Date: Sat, 04 Jan 2025 11:08:50 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, 75322 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.