Subject: Re: bug#75551: Potentially erroneous long loop in lrealloc

From: Hong Xu <[email-masked]>
Date: Wed, 15 Jan 2025 16:11:07 -0800

On 2025-01-14 Tue 13:04 GMT-08, Paul Eggert <[email-masked]> wrote:

> On 2025-01-13 19:34, Eli Zaretskii wrote:
>>> Consider a host where MALLOC_IS_LISP_ALIGNED is false and p %
>>> LISP_ALIGNMENT is frequently nonzero. if lrealloc is called with size
>>> being a multiplier of LISP_ALIGNMENT, the loop can take a long time to
>>> end until p % LISP_ALIGNMENT == 0, potentially until OOM.
>>>
>>> Based on my understanding, this part is to address some "oddball" hosts
>>> (based on the comment in alloc.c). But this does seem like a bug to me
>>> if Emacs is running on such an oddball host...
>> Paul, could you please comment on this?
>
> As far as we know, there are no oddball hosts.
>
> If Emacs is ever built on an oddball host, the code will operate correctly
> albeit possibly very inefficiently (perhaps including unwanted memory
> exhaustion).
>
> Alternatively, the code could simply run emacs_abort() instead of retrying the
> allocation. There should be no difference on today's platforms so it's no big
> deal either way.
>
> Or we could even remove the runtime test entirely, i.e., remove lrealloc and
> simply call realloc. That would make Emacs a bit faster in Lisp allocation.

It seems like the code is a bit less ideal to me -- on an imaginary
oddball host, this memory exhaustion bug is so frequent that I would
rather consider Emacs unsupported on such an oddball host.

I agree that it may be better to just remove lrealloc -- the memory
allocation code is so twisted that it can become a potential
hazard of security bugs on a normal host. We can add a compile time
check so that Emacs can't compile on an oddball host -- if there is
really one.

If an odd host indeed exists, I think the it's a simpler and cleaner
solution to replace the implementation of realloc with an aligned while
inefficient one, while keeping the logic of normal hosts intact.

What do you think?

-- 
Hong