GNU bug report logs - #74744
Build failure: SEGV in temacs (with "Pure Lisp storage overflowed")

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74744 in the body.
You can then email your comments to 74744 AT debbugs.gnu.org in the normal way.

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

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

From: Eric Marsden <eric.marsden <at> risk-engineering.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Build failure: SEGV in temacs (with "Pure Lisp storage overflowed")
Date: Mon, 9 Dec 2024 11:48:27 +0100

Hello,
Building current HEAD (6df535788a20c9047d33dd8a0c62258597632647) on Linux/AMD64 fails with a SEGV.
I see that there is a "Pure Lisp storage overflowed" message which is perhaps related.

Loading image...
Loading international/fontset...
Loading dnd...
Pure Lisp storage overflowed
Loading tool-bar...
Loading dynamic-setting...
Loading pgtk-dnd...
Loading touch-screen...
Loading term/common-win...
Loading term/pgtk-win...
Loading mwheel...
Loading progmodes/elisp-mode...
Loading emacs-lisp/float-sup...
Loading vc/vc-hooks...
Loading vc/ediff-hook...
Loading uniquify...
Loading electric...
Loading paren...
Loading emacs-lisp/shorthands...
Loading emacs-lisp/eldoc...
Fatal error 11: Segmentation fault
Backtrace:
./temacs(emacs_backtrace+0x3b) [0x5555556f98ab]
./temacs(terminate_due_to_signal+0x7c) [0x5555555dbbd4]
./temacs(+0x883dc) [0x5555555dc3dc]
./temacs(+0x30c4b8) [0x5555558604b8]
/lib/x86_64-linux-gnu/libc.so.6(+0x3fce0) [0x7ffff32c9ce0]
./temacs(+0x234058) [0x555555788058]
./temacs(+0x234013) [0x555555788013]
./temacs(+0x234013) [0x555555788013]
./temacs(+0x234013) [0x555555788013]
./temacs(+0x23458b) [0x55555578858b]
./temacs(Fputhash+0x53) [0x55555578bd33]
./temacs(+0x1f6619) [0x55555574a619]
./temacs(Fdefalias+0xb8) [0x555555759528]
./temacs(eval_sub+0x9cd) [0x555555772f0d]
./temacs(+0x256cdd) [0x5555557aacdd]
./temacs(Fload+0xb9f) [0x5555557aba9f]
./temacs(eval_sub+0x9a3) [0x555555772ee3]
./temacs(+0x256cdd) [0x5555557aacdd]
./temacs(Fload+0xb9f) [0x5555557aba9f]
./temacs(eval_sub+0x9a3) [0x555555772ee3]
./temacs(+0x183869) [0x5555556d7869]
./temacs(internal_condition_case+0x6f) [0x55555576c3af]
./temacs(+0x1838cd) [0x5555556d78cd]
./temacs(internal_catch+0x41) [0x55555576c2b1]
./temacs(+0x183c60) [0x5555556d7c60]
./temacs(recursive_edit_1+0xaf) [0x5555556d7d5f]
./temacs(Frecursive_edit+0x10b) [0x5555556d7f4b]
./temacs(main+0x2117) [0x5555555e6937]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d68) [0x7ffff32b3d68]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7ffff32b3e25]
./temacs(_start+0x21) [0x5555555e7021]

Configure flags: --prefix=/opt/emacs --enable-link-time-optimization
  --with-x-toolkit=no --with-tree-sitter --with-pgtk --with-native-compilation=yes
gcc (Debian 14.2.0-8) 14.2.0

Configured for 'x86_64-pc-linux-gnu'.
  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc -g3 -O2 -flto=8 -ffat-lto-objects
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    pgtk
  What toolkit should Emacs use?                          GTK3
  Where do we find X Windows header files?                Standard dirs
  Where do we find X Windows libraries?                   Standard dirs
  Does Emacs use -lXaw3d?                                 no
  Is Emacs being built for Android?                       no
  Does Emacs use the X Double Buffer Extension?           no
  Does Emacs use -lXpm?                                   no
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes -lgif
  Does Emacs use a png library?                           yes -lpng16
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use -lwebp?                                  yes
  Does Emacs use -lsqlite3?                               yes
  Does Emacs use cairo?                                   yes
  Does Emacs use -llcms2?                                 yes
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  no
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   yes
  Does Emacs use -ldbus?                                  yes
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               yes
  Does Emacs use a file notification library?             yes (inotify)
  Does Emacs use access control lists?                    yes -lacl -lattr
  Does Emacs use -lselinux?                               yes
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              yes
  Does Emacs use HarfBuzz?                                yes
  Does Emacs use -lm17n-flt?
  Does Emacs use -lotf?                                   yes
  Does Emacs use -lxft?
  Does Emacs use -lsystemd?                               yes
  Does Emacs use -ltree-sitter?                           yes
  Does Emacs use the GMP library?                         yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   yes
  Does Emacs use version 2 of the X Input Extension?      no
  Does Emacs generate a smaller-size Japanese dictionary? no

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eric Marsden <eric.marsden <at> risk-engineering.org>
Cc: 74744 <at> debbugs.gnu.org
Subject: Re: bug#74744: Build failure: SEGV in temacs (with "Pure Lisp storage
 overflowed")
Date: Mon, 09 Dec 2024 12:41:47 +0000

"Eric Marsden" <eric.marsden <at> risk-engineering.org> writes:

> Hello,
> Building current HEAD (6df535788a20c9047d33dd8a0c62258597632647) on Linux/AMD64 fails with a SEGV.
> I see that there is a "Pure Lisp storage overflowed" message which is perhaps related.

Yes, crashes after purespace overflow are currently expected, and they
regularly happen if you build in a directory that has .elc files from
previous builds in it.

If `make bootstrap' (which removes the .elc files) doesn't help, please
find out by how much you need to increase BASE_PURESIZE in puresize.h
for the build to succeed.

(There's some logic in the Emacs sources that would calculate the number
for you, but that's also broken and has been for ages, so you'll have to
experiment.)

Sorry that the poor state of the Emacs source code forces you to waste
your time on rediscovering well-known bugs.

Pip

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Marsden <eric.marsden <at> risk-engineering.org>
Cc: 74744 <at> debbugs.gnu.org
Subject: Re: bug#74744: Build failure: SEGV in temacs (with "Pure Lisp storage
 overflowed")
Date: Mon, 09 Dec 2024 17:03:24 +0200

> Date: Mon, 9 Dec 2024 11:48:27 +0100
> From: Eric Marsden <eric.marsden <at> risk-engineering.org>
> 
> Hello,
> Building current HEAD (6df535788a20c9047d33dd8a0c62258597632647) on Linux/AMD64 fails with a SEGV.
> I see that there is a "Pure Lisp storage overflowed" message which is perhaps related.

And if you enlarge PURESIZE, does the segfault go away?

Also, please try without --enable-link-time-optimization and without
the -flto=8 -ffat-lto-objects compiler options.

If all of the above doesn't help, please run the crashing command
under GDB and show a backtrace from the crash.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Marsden <eric.marsden <at> risk-engineering.org>
Cc: 74744 <at> debbugs.gnu.org
Subject: Re: bug#74744: Build failure: SEGV in temacs (with "Pure Lisp storage
 overflowed")
Date: Mon, 09 Dec 2024 18:27:47 +0200

> Date: Mon, 9 Dec 2024 16:23:56 +0100
> Cc: 74744 <at> debbugs.gnu.org
> From: Eric Marsden <eric.marsden <at> risk-engineering.org>
> 
> On 09/12/2024 16:03, Eli Zaretskii wrote:
> > And if you enlarge PURESIZE, does the segfault go away?
> >
> > Also, please try without --enable-link-time-optimization and without
> > the -flto=8 -ffat-lto-objects compiler options.
> 
> Thanks, inspired by Pip's suggestion I used
> 
>    ./configure --with-options
>    make FAST=true bootstrap
> 
> which worked, so I have not investigated further. I was not anticipating
> that the default make recipe might fail due to pre-existing object files.

Yes, pure space can overflow if loadup loads byte-compiled files.
This is a known subtlety that sometimes pops up.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Eric Marsden <eric.marsden <at> risk-engineering.org>
Cc: 74744 <at> debbugs.gnu.org
Subject: Re: bug#74744: Build failure: SEGV in temacs (with "Pure Lisp storage
 overflowed")
Date: Tue, 24 Dec 2024 02:50:02 +0000

tags 74744 + pending
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Mon, 9 Dec 2024 16:23:56 +0100
>> Cc: 74744 <at> debbugs.gnu.org
>> From: Eric Marsden <eric.marsden <at> risk-engineering.org>
>>
>> On 09/12/2024 16:03, Eli Zaretskii wrote:
>> > And if you enlarge PURESIZE, does the segfault go away?
>> >
>> > Also, please try without --enable-link-time-optimization and without
>> > the -flto=8 -ffat-lto-objects compiler options.
>>
>> Thanks, inspired by Pip's suggestion I used
>>
>>    ./configure --with-options
>>    make FAST=true bootstrap
>>
>> which worked, so I have not investigated further. I was not anticipating
>> that the default make recipe might fail due to pre-existing object files.
>
> Yes, pure space can overflow if loadup loads byte-compiled files.
> This is a known subtlety that sometimes pops up.

Given that we are planning to remove pure space, maybe this bug should
be closed.  I'm tagging it as pending for now.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74744-done <at> debbugs.gnu.org,
 Eric Marsden <eric.marsden <at> risk-engineering.org>
Subject: Re: bug#74744: Build failure: SEGV in temacs (with "Pure Lisp storage
 overflowed")
Date: Wed, 1 Jan 2025 19:51:46 -0600

Stefan Kangas <stefankangas <at> gmail.com> writes:

> tags 74744 + pending
> thanks
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Mon, 9 Dec 2024 16:23:56 +0100
>>> Cc: 74744 <at> debbugs.gnu.org
>>> From: Eric Marsden <eric.marsden <at> risk-engineering.org>
>>>
>>> On 09/12/2024 16:03, Eli Zaretskii wrote:
>>> > And if you enlarge PURESIZE, does the segfault go away?
>>> >
>>> > Also, please try without --enable-link-time-optimization and without
>>> > the -flto=8 -ffat-lto-objects compiler options.
>>>
>>> Thanks, inspired by Pip's suggestion I used
>>>
>>>    ./configure --with-options
>>>    make FAST=true bootstrap
>>>
>>> which worked, so I have not investigated further. I was not anticipating
>>> that the default make recipe might fail due to pre-existing object files.
>>
>> Yes, pure space can overflow if loadup loads byte-compiled files.
>> This is a known subtlety that sometimes pops up.
>
> Given that we are planning to remove pure space, maybe this bug should
> be closed.  I'm tagging it as pending for now.

I'm closing this bug report now.

Previous Next

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