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

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Mon, 9 Jun 2025 22:34:02 UTC

Severity: normal

Done: Pip Cet <pipcet <at> protonmail.com>

Full log


View this message in rfc822 format

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

> "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);

Thank you both!  I did not grep this xsignal 😅
-- 
Manuel Giraud




This bug report was last modified 7 days ago.

Previous Next


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