bug#51007: 27.2; emacs hangs when using window-toggle-side-windows

[Eli Zaretskii]

> Cc: indrajeet.khandekar@taranawireless.com, 51007@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 10 Oct 2021 14:31:06 +0200
> 
>  >> How would I do that?  These are structures like
>  >>
>  >> (gdb) p r->glyphs[TEXT_AREA]
>  >> $1 = (struct glyph *) 0xe2df90
>  >> (gdb) p fr->glyphs[TEXT_AREA]
>  >> $2 = (struct glyph *) 0xe36690
>  >
>  > These are the values I meant: the above shows the window's glyph
>  > matrix and the frame's glyph matrix are unrelated.  Not sure how that
>  > happened; perhaps one of them was recently reallocated?
> 
> IIUC these are the beginning of the root's and the frame's text areas
> where on TTYs the former must be embedded in the latter (1) when mapped
> to the screen and (2) within the memory of my computer.  So if the root
> matrix starts before the frame matrix in my memory I have a bug.  Is
> that interpretation correct?

Yes, AFAIU.
>  >> I suppose 'delete-other-windows-internal' mangles the window dimensions
>  >> but the scenarios work on GUI frames and pass all internal checks here
>  >> so it will take me some time to sort this out ...
>  >
>  > On GUI frames, the window's glyph matrices are allocated separately
>  > and there's no frame glyph matrix to begin with.
> 
> Which means that my first scenario cannot happen on GUIs.  I'm still
> surprised that GUI frames apparently swallow quite a number of bogus
> values without serious implications.

I think they just don't check, because there's no way of checking
that, unlike on TTY frames.  Glyph matrices of windows on GUI frames
are completely independent, and GUI frames don't have glyph matrices.