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

Previous Next

To reply to this bug, email your comments to 78738 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 #8 received at 78738 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78738 <at> debbugs.gnu.org
Subject: Re: bug#78738: (signal nil 5) crashes Emacs
Date: Tue, 10 Jun 2025 06:22:49 +0000

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

Note that there are currently many ways to crash Emacs by executing
dodgy Elisp; I think there should be fewer, but others appear to
disagree.  We specifically added an eassert to crash Emacs when a Lisp
function returns invalid data, for example.

Pip

Message #11 received at 78738 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 78738 <at> debbugs.gnu.org
Subject: Re: bug#78738: (signal nil 5) crashes Emacs
Date: Mon, 09 Jun 2025 23:43:17 -0700

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

> "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);
>
> Note that there are currently many ways to crash Emacs by executing
> dodgy Elisp; I think there should be fewer, but others appear to
> disagree.  We specifically added an eassert to crash Emacs when a Lisp
> function returns invalid data, for example.

Yeah, that should work.  The general theme of Fsignal seems to be
turning random passed-in stuff into a "peculiar error", so it seems
appropriate that it do the same for this specific set of parameters,
especially since the nil error_symbol behavior isn't documented.

Message #14 received at 78738 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: dancol <at> dancol.org, 78738 <at> debbugs.gnu.org
Subject: Re: bug#78738: (signal nil 5) crashes Emacs
Date: Tue, 10 Jun 2025 14:12:58 +0300

> 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.

Message #17 received at 78738 <at> debbugs.gnu.org (full text, mbox):

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

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.

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.
-- 
Manuel Giraud

Message #22 received at 78738-done <at> debbugs.gnu.org (full text, mbox):

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

Message #25 received at 78738 <at> debbugs.gnu.org (full text, mbox):

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

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Pip Cet <pipcet <at> protonmail.com>,  dancol <at> dancol.org,  78738 <at> debbugs.gnu.org
> Date: Tue, 10 Jun 2025 13:46:10 +0200
> 
> 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.

  void
  memory_full (size_t nbytes)
  {
    if (!initialized)
      fatal ("memory exhausted");
    [...]
    xsignal (Qnil, Vmemory_signal_data);
  }

Message #28 received at 78738-done <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #31 received at 78738 <at> debbugs.gnu.org (full text, mbox):

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

> Date: Tue, 10 Jun 2025 12:19:07 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, dancol <at> dancol.org, 78738-done <at> debbugs.gnu.org
> 
> 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.

My builds are 32-bit, so I do see it (rarely).

> 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.

Some users report very large memory footprints of the Emacs process
they sometimes see in a long-running session.

Keep in mind that "memory-full" doesn't mean we exceed the huge 64-bit
address space, just the total VM of the system, which is still
possible, even in a 64-bit build, especially if the amount of swap is
configured sub-optimally.

Previous Next

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