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

Message #59 received at 75459 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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 14:46:40 +0000

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

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> 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

Previous Next

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