Subject: Re: bug#79116: 31.0.50; Crash on IGC build

From: Pip Cet <[email-masked]>
Date: Wed, 30 Jul 2025 12:51:24 +0000

"Helmut Eller" <[email-masked]> writes:

> 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.

Good catch!

I think you're absolutely correct. What we do there definitely isn't
correct: if one of the frame's pools is behind a read barrier, there's a
tiny race condition, but a write barrier would effectively be ignored,
which might well cause problems like this one.

But we should fix it even if it didn't cause this particular crash.
igc_xpalloc_ambig shouldn't be hard to do, but it's probably better for
performance to turn glyph pools into their own IGC object type.

Pip