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

Previous Next

Package: emacs;

Reported by: Gregor Zattler <telegraph <at> gmx.net>

Date: Thu, 6 Feb 2025 12:51:01 UTC

Severity: normal

Found in version 31.0.50

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd.moellmann <at> gmail.com, 76091 <at> debbugs.gnu.org, telegraph <at> gmx.net, eller.helmut <at> gmail.com
Subject: bug#76091: 31.0.50; festure/igc: buffer.h:829: Emacs fatal error: assertion failed: BUFFERP (a)
Date: Sat, 08 Feb 2025 09:23:16 +0200
> Date: Fri, 07 Feb 2025 19:43:18 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Helmut Eller <eller.helmut <at> gmail.com>, Gregor Zattler <telegraph <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>, 76091-done <at> debbugs.gnu.org
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> >>> Well, yes.  I'll split it up into individual patches, so we can review
> >>> them one by one?
> >>
> >> Not necessary, but thanks.
> >
> > I'm through. Except for the shrinking case that you already mentioned I haven't found other problems.
> >
> > So LGTM.
> 
> Thanks!
> 
> Hope I didn't break anything, but I just pushed the series.  Please feel
> free to revert or fix as appropriate!

Here I get compilation warnings:

  igc.c: In function 'igc_realloc_ambig':
  igc.c:3324:55: warning: potential null pointer dereference [-Wnull-dereference]
   3324 |   ptrdiff_t old_size = (char *)r->d.end - (char *)r->d.start;
	|                                                   ~~~~^~~~~~
  igc.c:3324:36: warning: potential null pointer dereference [-Wnull-dereference]
   3324 |   ptrdiff_t old_size = (char *)r->d.end - (char *)r->d.start;
	|                                ~~~~^~~~
  igc.c:3324:55: warning: potential null pointer dereference [-Wnull-dereference]
   3324 |   ptrdiff_t old_size = (char *)r->d.end - (char *)r->d.start;
	|                                                   ~~~~^~~~~~
  igc.c:3324:36: warning: potential null pointer dereference [-Wnull-dereference]
   3324 |   ptrdiff_t old_size = (char *)r->d.end - (char *)r->d.start;
	|                                ~~~~^~~~
  igc.c: In function 'igc_xpalloc_exact':
  igc.c:3397:27: warning: argument to variable-length array may be too large [-Wvla-larger-than=]
   3397 |       volatile mps_word_t area[(item_size + (sizeof (mps_word_t) - 1))
	|                           ^~~~
  igc.c:3397:27: note: limit is 4031 bytes, but argument may be as large as 4294967292
  igc.c: In function 'igc_xnrealloc_ambig':
  igc.c:3415:57: warning: potential null pointer dereference [-Wnull-dereference]
   3415 |   ptrdiff_t old_nbytes = (char *)r->d.end - (char *)r->d.start;
	|                                                     ~~~~^~~~~~
  igc.c:3415:38: warning: potential null pointer dereference [-Wnull-dereference]
   3415 |   ptrdiff_t old_nbytes = (char *)r->d.end - (char *)r->d.start;
	|                                  ~~~~^~~~
  igc.c:3415:57: warning: potential null pointer dereference [-Wnull-dereference]
   3415 |   ptrdiff_t old_nbytes = (char *)r->d.end - (char *)r->d.start;
	|                                                     ~~~~^~~~~~
  igc.c:3415:38: warning: potential null pointer dereference [-Wnull-dereference]
   3415 |   ptrdiff_t old_nbytes = (char *)r->d.end - (char *)r->d.start;
	|                                  ~~~~^~~~

Most of them seem to be because root_find can return NULL.  The nit
about arena[] is probably because one cannot use sizeof and variables
in an array declaration?  We should probably either use the maximum as
a constant, or use alloca instead.

This is a 32-bit build on MS-Windows.

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?  Or did you
install some workaround for the above?




This bug report was last modified 102 days ago.

Previous Next


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