GNU bug report logs - #78738
(signal nil 5) crashes Emacs

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pip Cet <pipcet <at> protonmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#78738: closed ((signal nil 5) crashes Emacs)
Date: Tue, 10 Jun 2025 12:20:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Tue, 10 Jun 2025 12:19:07 +0000
with message-id <87cybb3i2x.fsf <at> protonmail.com>
and subject line Re: bug#78738: (signal nil 5) crashes Emacs
has caused the debbugs.gnu.org bug report #78738,
regarding (signal nil 5) crashes Emacs
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
78738: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78738
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: (signal nil 5) crashes Emacs
Date: Mon, 09 Jun 2025 15:33:38 -0700

(signal nil 5) crashes Emacs

[Message part 3 (message/rfc822, inline)]

From: Pip Cet <pipcet <at> protonmail.com>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dancol <at> dancol.org, 78738-done <at> debbugs.gnu.org
Subject: Re: bug#78738: (signal nil 5) crashes Emacs
Date: Tue, 10 Jun 2025 12:19:07 +0000

"Manuel Giraud" <manuel <at> ledu-giraud.fr> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Cc: 78738 <at> debbugs.gnu.org
>>> 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" <bug-gnu-emacs <at> gnu.org>
>>>
>>> "Daniel Colascione" <dancol <at> dancol.org> 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

Previous Next

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