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

From: Gerd Möllmann <[email-masked]>
Date: Thu, 31 Jul 2025 19:16:27 +0200

Helmut Eller <[email-masked]> writes:

> On Thu, Jul 31 2025, Gerd Möllmann wrote:
>
>> BTW, glyph pools are only used for tty frames. Don't know if that 
>> a role here.
>
> I didn't know that.  And the glyph matrix, is that a tty-only thing
> too?

No, every window has a glyph matrix. On ttys, window glyph matrices are
sub-allocated from a frame matrix, and all matrices are allocated from
glyph pools. On GUIs there are neither frame matrices nor glyph pools,
and windows manage the matrix memory themselves.

See dispnew.c, allocate_matrices_for_window_redisplay, and
allocate_matrices_for_frame_redisplay.

> Anyway, my concern is a bit more general: I think that objects without
> memory barriers, (e.g. structs allocated with malloc) should be scanned
> as roots.
>
> E.g. in fix_frame there is code that uses FRAME_FONT and to get the
> address of some field in a device dependent struct.  This struct is not
> protected by a memory barrier; I think these kind of structs should be
> roots.
>
> In the MPS paper, section "Phase 4: Black Mutator Tracing", they say
> that gray and white segments are read protected.  I assume that also
> means that, at his point, there are no write barriers.  If the mutator
> can read a pointer to a white object from a struct without read barriers
> and put the white pointer in a black object, then we have a problem.
> That's why I think that structs without memory barriers should be roots.
>
> There might be special circumstances where code like in fix_frame is
> sufficient.  E.g. if for some reason all paths to the font field go
> though the read-protected frame.  But I think those special conditions
> are hard to think about and it would be simpler to just make the thing a
> root.

Hm, could be. And what you say makes sense to me, as a potential
problem. I've never studied the MPS implementation in depth, so I don't
know if they take this into account, and have something for this case.

The only thing I remember from the docs is that one is allowed, while
scanning, in our case in the fix functions, to access non-MPS memory. I
don't think the docs say that one may not scan such non-MPS memory. But
I could be wrong of course, or it's something missing in the docs.

Hm, don't know what's best to do. At least it can't be the reason for
the current case, right?

OTOH, making the pools roots is also not a catastrophe either. BTW, The
frame in struct glyph is only used on ttys, it's something for child
frames on ttys. That's why I scan only the pools, from which all
matrices are sub-allocated.