GNU bug report logs - #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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org
Subject: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
Date: Fri, 10 Jan 2025 13:46:40 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> 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.

That explains why "backtrace" doesn't show up; it doesn't explain why
backtrace_function asserts on data that we previously ensured would be of
the right kind.

As the stack pointer is nowhere near the data that was clobbered, I have
no idea what's going on here.  .gdbinit ensures we're looking at a frame
with pdl->kind == SPECPDL_BACKTRACE, we call backtrace_function, which
is meant to be backtrace_function_body, which easserts the very same
thing we just tested, but finds it is no longer true.

Maybe backtrace_function is no longer equal to backtrace_function_body,
but backtrace_function should be in the .rodata section, which should be
protected against modification (but GDB has no problem modifying it, and
doesn't even issue a warning when doing so; another GDB bug, IMHO).

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

I don't think so: barriers don't cause SIGABRT (not even when the
"barrier" is unknown and MPS gives up; in that case, MPS restores the
SIGSEGV handler and raises SIGSEGV again; I think that's an MPS bug,
BTW: what MPS should do is to restore the SIGSEGV handler and return
from the handler, which will cause the faulting instruction to be
re-executed, which will, in turn, call the original SIGSEGV handler with
a siginfo structure), and the eassert in backtrace_function accesses the
specpdl, which is (unfortunately) an unprotected root.

> 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

Does lldb allow you to inspect memory that is behind a barrier?

GDB does (which is good), but doesn't warn about it in any way.  That is
very, very confusing behavior.  I think it qualifies as a GDB bug which
should be fixed (but the last GDB bug I reported was a +1 on a
20-year-old bug report that was never responded to in any way, so maybe
reporting further GDB bugs is a waste of time).

I don't think the decision to abort MPS and access the data in whatever
(presumably inconsistent) state it was left in is one that should be
made automatically, and that applies both to calling Emacs functions and
to using GDB commands.

If calling backtrace in GDB means we can't continue afterwards, that
would be very bad.  I think it's already bad that we automatically
append the Lisp backtrace to "bt" output.  IMHO, "bt" should limit
itself to accessing process memory via PTRACE, not call into application
code.  Making it destroy the Emacs session even when we can get a
backtrace would be worse.

Pip

Previous Next

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