GNU bug report logs - #79116
31.0.50; Crash on IGC build

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: spd <at> toadstyle.org, pipcet <at> protonmail.com, 79116 <at> debbugs.gnu.org
Subject: bug#79116: 31.0.50; Crash on IGC build
Date: Wed, 30 Jul 2025 15:28:10 +0300

> Cc: Sean Devlin <spd <at> toadstyle.org>, 79116 <at> debbugs.gnu.org
> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Wed, 30 Jul 2025 05:43:48 +0200
> 
> On Tue, Jul 29 2025, Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
> 
> > Thanks for the report. I'm afraid we don't have very much to go on: this
> > assertion in trace.c in MPS failed:
> >
> >     AVER(RefSetSub(ScanStateUnfixedSummary(ss), SegSummary(seg))); /* <design/check/#.common> */
> 
> This may or may not be relevant: the GC literature defines a weak and a
> strong tricolor invariant.  I wonder if this code checks those
> invariants.
> 
> In fix_frame, we do something that may not be kosher: we trace the glyph
> pool.  We can access the glyph pool because it lives outside the GC heap
> and has no memory barriers (and the world is stopped).  However, MPS may
> assume that we scan such regions as roots because there are no memory
> barriers on them to enforce the tricolor invariants.  I don't understand
> the invariants well enough to tell if what we do is harmless or not.
> Perhaps someone who does could think this through.

You seem to be talking about the data structures manipulated by the
display engine, but the thread which got hit with SIGABRT was not the
main thread (which indeed was in redisplay), it's some other thread.
And I wonder how come that other thread called MPS.

Previous Next

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