GNU bug report logs -
#75322
SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Previous Next
Full log
Message #122 received at 75322 <at> debbugs.gnu.org (full text, mbox):
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
> Date: Sun, 05 Jan 2025 09:19:17 +0100
>
> I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored
> in the memory allocated.
Is only SAFE_NALLOCA a potential problem? What about the other
members of the SAFE_*ALLOC* family?
> If that is a reference to MPS-allocated memory
> (a pointer or Lisp_Object), it should be changed, because it then hides
> references from MPS in malloc'd memory. Or can hide, to be more precise,
> in the case it doesn't use alloca.
Does using igc_xnmalloc_ambig have any significant adverse effect on
GC? Like makes it slower or forces it to scan more memory? Because
if we make SAFE_NALLOCA do this by default, there could be quite a lot
more such ambiguous roots by the time GC starts.
If this could impact performance or has some other adverse effects,
I think I'd prefer to have a new argument to SAFE_NALLOCA telling it
whether to call igc_xnmalloc_ambig, and we will then need to audit our
code to use that argument where what's stored in the memory it
allocates could be a Lisp object. This is more error-prone, but
performance does count, especially where it comes to GC.
> I think the performance impact of that is negligible because this
> path is only executed when SAFE_ALLOCA does not use alloca.
MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make
it significantly larger), so I'm not sure your assumption about
negligible performance impact is necessarily correct.
This bug report was last modified 147 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.