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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.

Ah, that explains it, thanks! Didn't know about that hook.

Could the problem then perhaps be barriers? In emacs_lldb.py I have, for
LLDB, a command

  def xpostmortem(debugger, command, ctx, result, internal_dict):
      """Call igc_postmortem to set MPS arena to postmortem state"""
      debugger.HandleCommand(f"expr igc_postmortem()")

I call that command manually when MPS gets in the way. Here is the
description from MPS

void mps_arena_postmortem(mps_arena_t arena)?
Put an arena into the postmortem state.

arena is the arena.

In the postmortem state, incremental collection does not take place,
objects do not move in memory, references do not change, the staleness
of location dependencies does not change, and memory occupied by
unreachable objects is not recycled. Additionally, all memory protection
is removed, and memory may be in an inconsistent state.

Warning

After calling this function, memory managed by the arena is not in a
consistent state, and so it is no longer safe to continue running the
client program. This function is intended for postmortem debugging only.
This function must be called from the thread that holds the arena lock
(if any thread holds it). This is the case if the program is
single-threaded, or if it is called from an MPS assertion handler. When
calling this function from the debugger, check the stack to see which
thread has the MPS arena lock.