bug#71224: 30.0.50; SIGSEGV in start_display

[Eli Zaretskii <eliz@gnu.org>]

> From: Daniel Clemente <n142857@gmail.com>
> Date: Thu, 30 May 2024 09:55:20 +0000
> Cc: 71224@debbugs.gnu.org
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00005555555d772f in redisplay_window (window=XIL(0x555556d13e05),
> just_this_one_p=false) at xdisp.c:19961
> 19961     *w->desired_matrix->method = 0;
> 
> (gdb) pp window
> #<window 411 on *scratch*>
> 
> (gdb) list 19961
> 19956
> 19957      SET_TEXT_POS (lpoint, PT, PT_BYTE);
> 19958      opoint = lpoint;
> 19959
> 19960    #ifdef GLYPH_DEBUG
> 19961      *w->desired_matrix->method = 0;
> 19962    #endif
> 19963
> 19964      if (!just_this_one_p && needs_no_redisplay (w))
> 19965        return;

That's not what I hoped for, sadly.  It's the same problem, just
detected a bit earlier.  A window with NULL glyph matrices cannot be
redisplayed, period.  That's why leaf windows _must_ have glyph
matrices.

> Maybe we need more GLYPH_DEBUG assertions to catch null glyph matrices sooner?

Yes, but where?  I don't understand how this situation could happen,
so it's hard to think about a good place to add assertions.

> I see similar checks in dispnew.c, e.g.:
> eassert (current_matrix && desired_matrix);

This is too late: update_frame_1, where this assertion lives, is
called after redisplay_window did its job.

> A next step for me could be setting up a breakpoint (or message) in
> the place where the glyph matrix is defined, to see if it's ever being
> defined, vs. it's defined and then cleared. But I'm still learning
> about glyph matrices and I don't know where they're expected vs. where
> null.

AFAIK, the glyph matrices are assigned to windows on TTY frames in
allocate_matrices_for_frame_redisplay:

	  /* If not already done, allocate sub-matrix structures.  */
	  if (w->desired_matrix == NULL)
	    {
	      w->desired_matrix = new_glyph_matrix (f->desired_pool);
	      w->current_matrix = new_glyph_matrix (f->current_pool);
	      *window_change_flags |= NEW_LEAF_MATRIX;
	    }

And new_glyph_matrix cannot return NULL (if we run out of memory,
new_glyph_matrix will signal a "memory-full" error).

It might be possible that the glyph matrices of a window are somehow
freed later, perhaps in free_window_matrices.  But all these places
are run as part of deleting a window under block_input, so I don't
quite see how a window with NULL glyph matrices could have been used
for anything...

> I'm also trying to get better at gdb to detect when a variable (e.g.
> w->desired_matrix) changes.

You are talking about watchpoints.  Something like

  (gdb) watch -l w->current_matrix

If nothing else helps, try that.  But I suspect it will be hard to
find the window whose matrices to watch, and the problem is how to
distinguish between windows that are being killed in your high-speed
scenario and windows that are still being used.

Thanks.

P.S. If no other ideas are brought up, I can think about a simple
band-aid we could try: refrain from redisplaying a window that doesn't
have glyph matrices.