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

[martin rudalics]

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

>> BTW, the bug is easily reproducible using the following scenario: With
>> a master emacs -Q in an -nw session I evaluate
>
> So you want me to debug it?

Don't bother.  The culprit sits in 'delete-other-windows-internal'.  I
apparently was just lucky that the assertion error triggered in one
scenario while in the other scenario Emacs somehow bypassed that check,
went into redisplay with bogus values and just got hung.

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

martin