Subject: bug#78738: closed (Re: bug#78738: (signal nil 5) crashes Emacs)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 10 Jun 2025 12:20:02 +0000

Your bug report

#78738: (signal nil 5) crashes Emacs

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
78738: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78738
GNU Bug Tracking System
Contact [email-masked] with problems

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

Subject: (signal nil 5) crashes Emacs
From: Daniel Colascione <[email-masked]>
To: [email-masked]
Date: Mon, 09 Jun 2025 15:33:38 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

(signal nil 5) crashes Emacs