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>

Bug is archived. No further changes may be made.

Full log


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.




This bug report was last modified 32 days ago.

Previous Next


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