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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: pipcet <at> protonmail.com, 75322 <at> debbugs.gnu.org
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Date: Sun, 05 Jan 2025 11:40:29 +0100

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

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

Haven't checked others yet. I have that on my todo list now.

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

More roots = more to scan for GC.

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

Works well for me so far. 

Previous Next

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