bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Pip Cet <pipcet@protonmail.com> writes:

> "Ihor Radchenko" <yantar92@posteo.net> writes:
>
> The most likely candidate right now is make_environment_block, which
> happily stuffs string data pointers into an xmalloc'd block and goes
> about its merry way without letting GC know about them.   I think it
> would cause the problem you observed, but haven't managed to reproduce
> it yet.  If I manage to do so, I'll push a fix.

There's definitely a bug there (inserting an igc_collect() will corrupt
the environment), and I'll fix it, but I'm a bit puzzled by the "Bad
address" thing, and I think there may be an additional bug (making four
overall for this very productive bug report):

How do syscalls and execve(), in particular, handle the case of a
pointer to MPS-managed memory which is behind an active memory barrier?
I'm pretty sure there's no SIGSEGV in this case, just an EFAULT.  Easily
fixable for execve, which accesses only a limited amount of data, but I
don't remember whether we ever read() or write() MPS-managed memory,
which I assume would eventually run into this bug.

If syscalls silently accept mprotect()ed mapped areas which are
currently inaccessible (they really shouldn't because it breaks w+x
protection!), that's an additional problem we need to work around,
because the memory contents might not be valid.  I don't think we(*)
ever read() or write() Lisp_Objects and expect useful results, so maybe
everything's okay in that case?

(*) - the fork()-based mark-and-sweep GC did, so it's not entirely
unreasonable to do that :-)

Pip