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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75292 <at> debbugs.gnu.org, Ihor Radchenko <yantar92 <at> posteo.net>, eggert <at> cs.ucla.edu
Subject: bug#75292: 31.0.50; igc: (file-error "Doing vfork" "Bad address")
Date: Fri, 10 Jan 2025 20:17:52 +0000

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

>> From: Ihor Radchenko <yantar92 <at> posteo.net>
>> Cc: eggert <at> cs.ucla.edu, 75292 <at> debbugs.gnu.org
>> Date: Tue, 07 Jan 2025 18:44:45 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I guess the next thing to try is to return to the posix_spawn build
>> > after callproc.c is patched as discussed in bug#75322.
>>
>> Do I understand correctly that the patch is not yet finalized?
>
> No.  It was installed, but then reverted.  The plan is to revert the
> revert, AFAIU.

If we reinstall that patch, we should not be fixing !HAVE_MPS bugs on
scratch/igc.  If we think there is one, we should install it on master;
if we think there isn't, we should #ifdef it so no changes apply to the
!HAVE_MPS build.

Please let me know which option you prefer.

(My *long-term* preference is option C: make it safe to call traditional
GC while an SDATA pointer is on the stack or in conservatively-scanned
heap regions, which we'd have to introduce first :-)

I got distracted and extended alloc.c conservative scanning to
automatically pin strings if there is a corresponding SDATA pointer on
the stack, and I was going to make conservative scanning apply to
SAFE_ALLOCA xmalloc'd memory next.  If we do that, we can just use
xmalloc_conservative in make_environment_block and SAFE_ALLOCA and we no
longer have to worry about that particular no-GC assumption.

My intention was to display strings with live SDATA pointers to find
bugs where alloc.c GC happens at the wrong time, helping us locate
live-SDATA-during-GC bugs (which would have been a strong argument for
applying the patch).  I couldn't find any, not even when I ramped up GC
to barely tolerable levels and always relocated every single unpinned
string.  I think such bugs exist but are limited to unlikely code paths,
such as the one where ENCODE_FILE calls Lisp, GCs, and destroys
call_process's SDATA pointers (I haven't been able to trigger this bug;
it may be prevented by some logic I missed).

This would make pin_string redundant, but there's also a risk that
constantly compacting all the bytecode objects that are NOT referenced
by the stack would make GC much slower.  It would prevent bugs similar
to this one, but this precise bug would not have been prevented because
the SDATA pointers were in xmalloc'd memory.)

Pip

Previous Next

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