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

Previous Next

Full log

Message #44 received at 75322 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 75322 <at> debbugs.gnu.org
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sat, 04 Jan 2025 11:08:50 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Cc: 75322 <at> debbugs.gnu.org
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Fri, 03 Jan 2025 21:34:07 +0100
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> >
>> > The pointers to string data case probably requires adding yet another
>> > macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root,
>> > possibly and exact one which would be good.
>>
>> Or one does it as you did in b0a209e9204, that's of course also safe.
>> For both old and new GC. (Don't remember if you mentioned it Pip, but
>> old GC moves string data as well, during string compaction, should GC
>> run).
>
> 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.

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

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.

> Is that assumption false with MPS?

As we agreed, code should be written to assume GC can strike at any
time.  In the context of MPS, to make things more difficult, "GC can
strike" may mean a full GC happens (moving objects) or a memory barrier
is lifted.

> 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.

Pip

Previous Next

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