Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland

[Pip Cet <pipcet@protonmail.com>]

"Eval Exec" <execvy@gmail.com> writes:

> Hello,
> I'm helping to test scratch/igc branch on my local environment:

Thank you!

> ```
> ❯ uname -a
> Linux Matrix 6.6.41 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 18 11:21:27
> UTC 2024 x86_64 GNU/Linux
> ```
>
> I get the source code of scratch/igc, commit hash: 6682d0e6c96 .
> And I append a new commit:
> ```
> diff --git a/src/igc.c b/src/igc.c
> index f069a2becc9..4d792da75c8 100644
> --- a/src/igc.c
> +++ b/src/igc.c
> @@ -4459,7 +4459,7 @@ make_arena (struct igc *gc)
>    MPS_ARGS_END (args);
>    IGC_CHECK_RES (res);
>
> -  mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
> +  mps_gen_param_s gens[] = { { 128000000, 0.8 }, { 5 * 128000000, 0.4 } };
>    res = mps_chain_create (&gc->chain, gc->arena, ARRAYELTS (gens), gens);
>    IGC_CHECK_RES (res);
>  }
> ```

Those numbers are in kilobytes, so that requests 640 gigabytes of memory
before it'll even start collecting in earnest.  In theory, that should
work given enough RAM or swap, but I doubt anyone's tested MPS with such
extreme settings.

> Then, I compile it by:
> ```
> make extraclean
> ./autogen.sh \
>   && ./configure \
>   --prefix=$(realpath ../emacs-build/$(git branch --show-current | sed
> 's/\//_/g'))\
>   --with-mps=yes \
>   --with-imagemagick  \
>   --with-modules --with-x-toolkit=gtk3 --without-compress-install \
>   --without-toolkit-scroll-bars --with-native-compilation  --with-mailutils\
>   --enable-link-time-optimization \
>   --with-tree-sitter --with-xinput2  \
>   --with-dbus  --with-native-compilation=aot \
>   --with-file-notification=inotify\
>   && make -j30 install
> ```
>
> When I launch the emacs, editing rust files, emacs crashed. the
> backtrace is:

How much memory was it using at the time?  To me it looks conceivable
the crash happened because we failed to get enough memory for a new
stack frame, but if it's reproducible or happens again after reducing
the generation sizes, we need to investigate it further.

> ```
> (gdb) source /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/.gdbinit
> warning: /home/exec/Projects/git.savannah.gnu.org/git/emacs/../lwlib:
> No such file or directory
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not
> from terminal]
> DISPLAY = :0
> TERM = tmux-256color
> Breakpoint 1 at 0x428ca7: file
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c, line
> 432.
> Breakpoint 2 at 0x52db40: file
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/xterm.c, line
> 27126.
> (gdb) bt
> #0  0x00007f36826a2efc in __pthread_kill_implementation () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #1  0x00007f3682652e86 in raise () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #2  0x0000000000428d5a in terminate_due_to_signal (sig=11,
> backtrace_limit=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/emacs.c:470
> #3  0x0000000000429579 in handle_fatal_signal (sig=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1800
> #4  0x00000000006c5a68 in deliver_thread_signal.constprop.0 (sig=11,
> handler=<optimized out>) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/sysdep.c:1792
> #5  <signal handler called>
> #6  0x00007f368265316b in kill () from
> /nix/store/dbcw19dshdwnxdv5q2g6wldj6syyvq7l-glibc-2.39-52/lib/libc.so.6
> #7  0x00000000007551e9 in sigHandle ()
> #8  <signal handler called>
> #9  indirect_function (object=XIL(0)) at
> /home/exec/Projects/git.savannah.gnu.org/git/emacs/src/lisp.h:1198

It would be good to know whether 'object' is actually nil in this case
(in which case lisp.h:1198 is wrong) or whether the nil is wrong (and
the lisp.h:1198, possibly, correct), but I suspect the best bet is to
reduce the generation chain sizes and try again.

> What information should I provide to help investigating this crash?

Trying again with a more moderate generation size would be ideal, but
you might want to run Emacs in GDB and keep it connected after a crash
so we can investigate further.

Thanks again
Pip