> Date: Thu, 5 Sep 2024 10:18:35 +0200 > Cc: n142...@gmail.com, 73...@debbugs.gnu.org > From: martin rudalics <rudal...@gmx.at> > > > Thanks, but could you tell how that change could have affected this > > assertion violation? > > I attach the patch now, sorry for not doing it earlier.
You didn't attach it, but I think I understood what you wanted to change, and did that by hand. > IIUC we are talking about this assertion > > eassert (frame_size_change_delayed (XFRAME (w->frame)) > || glyph_row_slice_p (window_row, frame_row)); > > Right? Yes. > If so, then this violation might be caused by the fact that we > (1) did resize windows according to the new sizes but (2) did not update > the frame sizes accordingly. Can you elaborate on how this could be possible? I always thought we first allocate the frame matrices, and then the window matrices (by suballocating them from the frame matrices). Am I mistaken? > > AFAICT, adjust_frame_glyphs is not in the > > backtrace, so how could moving code inside of it affect what happens > > here? > > I don't understand what you mean here. Moving code in adjust_frame_glyphs could affect the assertion if the assertion was being hit while adjust_frame_glyphs is still being executed. But that is not the case, so I don't understand how moving some code in adjust_frame_glyphs without changing it could affect the assertion violation. I'm probably missing something.
