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

From: Hong Xu <[email-masked]>
Date: Thu, 16 Jan 2025 13:46:53 -0800

On 2025-01-15 Wed 23:41 GMT-08, Paul Eggert <[email-masked]> wrote:

> On 2025-01-15 16:11, Hong Xu wrote:
>> 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
>
> Good points. Attached is a patch to make that change in a safe way. Please take
> a look at it and give it a try.

After applying the patch to the master branch, I'm getting a memory
exhaustion error when starting Emacs:

    $ ./src/temacs -Q
    emacs: memory exhausted

This is my backtrace:

#0  memory_full (nbytes=0) at ../../src/alloc.c:4319
#1  0x0000000000600854 in xrealloc (block=0x100f180, size=0) at ../../src/alloc.c:811
#2  0x00000000005e33cc in shrink_regexp_cache () at ../../src/search.c:150
#3  0x00000000006093f6 in garbage_collect () at ../../src/alloc.c:6526
#4  0x00000000006091a1 in maybe_garbage_collect () at ../../src/alloc.c:6442
#5  0x000000000063e2a6 in maybe_gc () at ../../src/lisp.h:5979
#6  0x0000000000645632 in Ffuncall (nargs=2, args=0x7fffffffacb0) at ../../src/eval.c:3077
#7  0x0000000000657397 in mapcar1 (leni=1472, vals=0x103eea0, fn=0x9f7c0, seq=0x8ccffb <pure+147227>) at ../../src/fns.c:3388
#8  0x000000000065789a in Fmapconcat (function=0x9f7c0, sequence=0x8ccffb <pure+147227>, separator=0x8a90e4 <pure+4>) at ../../src/fns.c:3475
#9  0x00000000006a604e in hash_native_abi () at ../../src/comp.c:798
#10 0x0000000000564adb in main (argc=2, argv=0x7fffffffb0a8) at ../../src/emacs.c:2499

Looks like realloc with size=0 need to be specifically handled as it
acts as freeing the memory and returns null.

-- 
Hong