all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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






  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.