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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 75292 <at> debbugs.gnu.org
Subject: Re: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 03 Jan 2025 19:11:58 +0000

Pip Cet <pipcet <at> protonmail.com> writes:

> "Ihor Radchenko" <yantar92 <at> 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

Previous Next

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