From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, telegraph@gmx.net, 75459@debbugs.gnu.org
Subject: 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
Date: Fri, 10 Jan 2025 14:46:40 +0000 [thread overview]
Message-ID: <878qri3ewj.fsf@protonmail.com> (raw)
In-Reply-To: <m25xmmyc9z.fsf@gmail.com>
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> 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.
>
> True.
>
>>> 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?
>
> No, or at least I don't know how I could do that.
It may have been unfair to call this a GDB bug: I don't know much about
the ptrace API, and if the ptrace API allows modifying rodata and
reading mprotected memory, there's a good chance that's a Linux kernel
bug which isn't present in whatever macOS uses instead.
Speaking of toolchain bugs, though, I appear to have "been" upgraded to
a new GCC version which produces many new warnings, including what
appears to me to be a false positive "null pointer dereference" (NOT a
"potential null pointer dereference") in dispnew.c.
(root_frame () can return a NULL pointer in some contexts, but not in
this one, so this is, at best, a *potential* null pointer dereference,
or a suggested additional assertion. A "null pointer dereference"
without a "potential" is reserved for code paths which can be proven
to dereference a null pointer, not for code paths which cannot be proven
not to. So this is a GCC bug.)
Still investigating the others, but:
In file included from json.c:31:
igc.h:88:7: warning: redundant redeclaration of ‘igc_xnmalloc_ambig’ [-Wredundant-decls]
88 | void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
| ^~~~~~~~~~~~~~~~~~
In file included from json.c:28:
lisp.h:6117:14: note: previous declaration of ‘igc_xnmalloc_ambig’ with type ‘void *(ptrdiff_t, ptrdiff_t)’ {aka ‘void *(long int, long int)’}
6117 | extern void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
| ^~~~~~~~~~~~~~~~~~
igc.h:90:6: warning: redundant redeclaration of ‘igc_xfree’ [-Wredundant-decls]
90 | void igc_xfree (void *p);
| ^~~~~~~~~
lisp.h:6118:13: note: previous declaration of ‘igc_xfree’ with type ‘void(void *)’
6118 | extern void igc_xfree (void *p);
| ^~~~~~~~~
seems annoying, but avoidable.
I'll push a "fix", but I wanted to explain why first: new useless GCC
warnings force us to do that.
Pip
next prev parent reply other threads:[~2025-01-10 14:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 11:19 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 Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 13:03 ` Eli Zaretskii
2025-01-09 14:34 ` Gerd Möllmann
2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 15:32 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 16:14 ` Gerd Möllmann
2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 13:59 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 4:52 ` Gerd Möllmann
2025-01-10 7:15 ` Eli Zaretskii
2025-01-10 7:29 ` Gerd Möllmann
2025-01-10 7:53 ` Eli Zaretskii
2025-01-10 8:14 ` Gerd Möllmann
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 14:27 ` Gerd Möllmann
2025-01-10 14:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2025-01-10 15:27 ` Gerd Möllmann
2025-01-10 14:44 ` Eli Zaretskii
2025-01-10 15:30 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 14:52 ` Gerd Möllmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qri3ewj.fsf@protonmail.com \
--to=bug-gnu-emacs@gnu.org \
--cc=75459@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=gerd.moellmann@gmail.com \
--cc=pipcet@protonmail.com \
--cc=telegraph@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.