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

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

[Eric Marsden]

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

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

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

"Eric Marsden" <eric.marsden@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

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

[Eli Zaretskii]

> Date: Mon, 9 Dec 2024 11:48:27 +0100
> From: Eric Marsden <eric.marsden@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.

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

[Eli Zaretskii]

> Date: Mon, 9 Dec 2024 16:23:56 +0100
> Cc: 74744@debbugs.gnu.org
> From: Eric Marsden <eric.marsden@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.