bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Gregor Zattler <telegraph@gmx.net>,  Eli Zaretskii <eliz@gnu.org>,
>   75459@debbugs.gnu.org
> Date: Fri, 10 Jan 2025 05:52:39 +0100
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> 
> >>> #0 terminate_due_to_signal (sig=sig@entry=6,
> > backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> >>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> >> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> >> "eval.c", line=line@entry=118) at ./src/alloc.c:8377
> >>> #2  0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> >>> #3  0x00007fffffff986f in <function called from gdb> ()
> 
> Another thing that irritates me is that I don't see emacs_backtrace in
> the bt. Die is there, which calls terminate_due_to_signal, but then we
> are immediately in backtrace_function. That makes no sense.

I think that's because we stopped before the call to emacs_backtrace:

> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> 432	{
> #0  terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #1  0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@entry=597) at ./src/alloc.c:8377

This happens because src/.gdbinit sets a breakpoint there:

  # When debugging, it is handy to be able to "return" from
  # terminate_due_to_signal when an assertion failure is non-fatal.
  break terminate_due_to_signal

The call to emacs_backtrace is further down in
terminate_due_to_signal.  It was not called yet.

The xbacktrace command is automatically called by GDB as a post-hook
of the "bt" (backtrace) command.  So when the functions called by GDB
to generate the Lisp backtrace crash, you see more calls to
terminate_due_to_signal, which again hit the above breakpoint.