GNU bug report logs - #76091
31.0.50; festure/igc: buffer.h:829: Emacs fatal error: assertion failed: BUFFERP (a)

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 76091 <at> debbugs.gnu.org, telegraph <at> gmx.net,
 eller.helmut <at> gmail.com
Subject: Re: bug#76091: 31.0.50;
 festure/igc: buffer.h:829: Emacs fatal error: assertion failed:
 BUFFERP (a)
Date: Sun, 09 Feb 2025 17:24:11 +0000

Pip Cet <pipcet <at> protonmail.com> writes:

> Oh, thanks! Yeah, I can see them in optimized builds, and they require
> eassume, not eassert.  I'll suggest a patch once I've thought of a good
> way to avoid those, but for now, we just might have to ignore the
> warnings.

Okay, patch pushed.  I still see warnings for some builds, but I don't
really know how to fix them.

Also fixed a minor oversight which caused trouble in the print code in
!HAVE_MPS builds.

>>> > Also, does this:
>>> >
>>> >> (Of course, with WIDE_EMACS_INT, mps_word_t is not good enough; unless
>>> >> we carefully write the scan function not to assume that the two
>>> >> half-words comprising a 64-bit Lisp_Object are in sync.  As Eli was very
>>> >> opposed to the idea of removing WIDE_EMACS_INT again, we might have to
>>> >> find a workaround there.)
>>> >
>>> > mean that the wide-int 32-bit build is now in trouble?
>>>
>>> Yes, it does.  All scanning functions need to be written to deal with
>>> half-written Lisp_Object values in that case.  (Easier than it sounds
>>> because we USE_LSB_TAG).
>>>
>>> > Or did you install some workaround for the above?
>>>
>>> Not yet :-)
>>
>> Hopefully, soon then?
>
> I don't think there are any fundamental problems there, but it needs
> some time and the setjmp() issues seem more important right now.
>
> (Two issues: nativecomp uses %rbp and may call setjmp directly, which
> scrambles the %rbp value before saving it in a jmp_buf.
>
> And it seems that push_handler_nosignal allocates the jmp_buf from a
> non-root but doesn't trace it in any way whatsoever. I have no idea why
> that isn't causing more frequent crashes....)

I think both these issues need fixing to avoid crashes with unusual
optimization options, but they should be fine for non-LTO builds.

Pip

Previous Next

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