Subject: Re: bug#78738: (signal nil 5) crashes Emacs
From: Pip Cet <[email-masked]>
To: Manuel Giraud <[email-masked]>
Cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
Date: Tue, 10 Jun 2025 12:19:07 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

"Manuel Giraud" <[email-masked]> writes:

> Eli Zaretskii <[email-masked]> writes:
>
>>> Cc: [email-masked]
>>> Date: Tue, 10 Jun 2025 06:22:49 +0000
>>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <[email-masked]>
>>>
>>> "Daniel Colascione" <[email-masked]> writes:
>>>
>>> > (signal nil 5) crashes Emacs
>>>
>>> Good catch!
>>>
>>> This would fix it, right?
>>>
>>> diff --git a/src/eval.c b/src/eval.c
>>> index fbb881d682d..be6d1a0a9ac 100644
>>> --- a/src/eval.c
>>> +++ b/src/eval.c
>>> @@ -1888,7 +1888,7 @@ DEFUN ("signal", Fsignal, Ssignal, 2, 2, 0,
>>>    (Lisp_Object error_symbol, Lisp_Object data)
>>>  {
>>>    /* If they call us with nonsensical arguments, produce "peculiar error".  */
>>> -  if (NILP (error_symbol) && NILP (data))
>>> +  if (NILP (error_symbol) && !CONSP (data))
>>>      error_symbol = Qerror;
>>>    signal_or_quit (error_symbol, data, false);
>>>    eassume (false);
>>
>> Thanks.  If this keeps bug#32961 solved, please install on the
>> emacs-30 branch, since this is a regression in Emacs 30.

I've confirmed that that produces a peculiar error, too, as do a few
other combinations.

So I've pushed this as commit 888f846d377.

> On this matter, what is the code path that leads to a call to
> signal_or_quit with a nil error_symbol parameter?  According to the
> comment at eval.c:1912, it means that the memory is full but I cannot
> figure out how we can get there.

memory_full in alloc.c calls

  /* This used to call error, but if we've run out of memory, we could
     get infinite recursion trying to build the string.  */
  xsignal (Qnil, Vmemory_signal_data);

There's another place that does the same for the REL_ALLOC case, in
buffer_memory_full.

It's questionable whether all the OOM code we have is still being
tested, since it's rare to run out of memory nowadays on 64-bit
machines.  I run into it once in a while when I've broken something
else, just like I've never seen a "peculiar error" that wasn't the
result of messing up Emacs internals elsewhere.

Pip